Wed 20 Feb 2008 05:26:13 PM UTC, comment #19:
seems to work here on freebsd
|
Wed 20 Feb 2008 02:52:34 PM UTC, comment #18:
Altered configure.ac to try to work around header dependencies on free bsd
|
Wed 20 Feb 2008 08:43:13 AM UTC, comment #17:
Any chance of a look at the configure log to find out why it's not finding the capability ... assuming that it's not something like the statvfs stuff not being built in to the kernel.
|
Mon 18 Feb 2008 04:01:36 PM UTC, comment #16:
> %obj/NSFMTest --GNU-Debug=NSFileManager
> 2008-01-21 22:31:23.754 NSFMTest[4748] File NSFileManager.m: 1795. In
> [NSFileManager -fileSystemAttributesAtPath:] no support for filesystem attributes
So ... on freebsd statvfs is not being found at configure time ... what we seem to have is a system specific problem with the autoconf configure script. Someone with a freebsd system simply needs to provide appropriate tweaks to copnfigure.ac
On all other systems examined, this actually appears to be working.
|
Tue 22 Jan 2008 09:47:30 PM UTC, comment #15:
I fixed GWOrkspace not to make any special bit shifts for BSD systems. That fixed NetBSD now, but for FreeBSD I still don't know.
|
Mon 21 Jan 2008 09:39:02 PM UTC, comment #14:
on FreeBSD
%obj/NSFMTest --GNU-Debug=NSFileManager
2008-01-21 22:31:23.754 NSFMTest[4748] File NSFileManager.m: 1795. In [NSFileManager -fileSystemAttributesAtPath:] no support for filesystem attributes
2008-01-21 22:31:23.761 NSFMTest[4748] free size is nil
|
Thu 17 Jan 2008 08:30:39 PM UTC, comment #13:
Looks like statvfs is being found on freebsd, so probably it's returning nil because the system call is failing for some reason.
I've added some debug code to svn to report the problem if you run a program with --GNU-Debug=NSFileManager
|
Thu 17 Jan 2008 07:44:55 PM UTC, comment #12:
on netbsd the test program works now. I need to check if workspace now works too.
on freebsd base configure says:
checking for sys/stat.h... (cached) yes
checking sys/vfs.h usability... no
checking sys/vfs.h presence... no
checking for sys/vfs.h... no
checking sys/statfs.h usability... no
checking sys/statfs.h presence... no
checking for sys/statfs.h... no
checking sys/statvfs.h usability... yes
checking sys/statvfs.h presence... yes
checking for sys/statvfs.h... yes
|
Thu 17 Jan 2008 02:23:18 PM UTC, comment #11:
Well, actually I just typed %lu. I was half past one in the morning and my mind was sleepy.
In any case the whole problems comes from GWorkspace, where I get the wrong free space information, which reports unknown on freebsd and a wrong size on netbsd (and not sjut twcie or the half depending on the default size of blocks).
I dug into the code and wrote the quick dirty test program just for that purpose. SOrry for it being too dirty.
I'll check for the configure script you need tomorrow
|
Thu 17 Jan 2008 08:36:41 AM UTC, comment #10:
I see I accidentally wrote '%lu' when I meant '%llu' ...
Sebastian wrote '%llu', so he obviously understood what I meant to say rather than what I actually wrote. Did you (Riccardo) actually test using the correct format for an unsigned long long or did you test using the format for an unsigned long?
Anyway, regardless of what's going on with formatting, the fact that you are getting nil on FreeBSD is plainly wrong.
Ideally you would just step through the method in gdb and see exactly what path of code is being executed to determine what the problem is.
However, the only way that a nil return is likely to happen assuming the filesystem you tell it to check is exists (ie that the argument you pass in is correct) is if the configure script used to build the base library failed to detect the presence of the expected header files on that system. The configure script looks for sys/vfs.h sys/statfs.h or sys/mount.h ... if it doesn't find any of these, can you see why?
|
Thu 17 Jan 2008 12:27:16 AM UTC, comment #9:
no sorry.. with current code i get. (while using %lu)
On NetBSD:
2008-01-17 01:28:04.061 NSFMTest[15606] size is 239753216
strider: {40} df -k
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/wd0a 18973646 5207918 12817046 28% /
kernfs 1 1 0 100% /kern
and on FreeBSD:
%obj/NSFMTest
2008-01-16 20:08:51.940 NSFMTest[2516] free size is nil
|
Wed 16 Jan 2008 06:33:49 AM UTC, comment #8:
Well, 10037696512 / 1024 is 9802438 ... which agrees with the output of df exactly, so it looks like there is no problem on OpenBSD and the bug is just the test program (unless things are different on NetBSD and FreeBSD).
|
Wed 16 Jan 2008 06:23:03 AM UTC, comment #7:
On OpenBSD 4.2 i386 the following happens:
df -k
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/wd0f 10318422 64 9802438 0% /home
run the test program with %llu in NSLog:
# obj/testtool
2008-01-16 07:21:27.535 testtool[5945] size is 10037696512
run the program with %u or %lu in NSLog:
# obj/testtool
2008-01-16 07:22:10.870 testtool[18361] size is 1447761920
|
Tue 15 Jan 2008 09:07:39 PM UTC, comment #6:
Looking at the attached test program, I see that the NSLog to print the free size uses '%d' (print a signed integer), but the argument passed to it is an 'unsigned long long' so the value printed could be totally wrong.
Does this mean that this bug report is a mistake? Or does the bug persist when the formatting is corrected to '%lu' ?
|
Tue 08 Jan 2008 09:22:07 AM UTC, comment #5:
Could you please provide the used test application? Otherwise it is hard to say for sure, if you are printing out the correct value.
From you comment I understand that the value you are looking for is the amount of free space.
Could you please add an NSLog() statement to the method fileSystemAttributesAtPath: to report the used block size? Either this is wrong, or things go wrong in the calculation. And you need BSD to test both.
Great that at least we only have one problem left, although my patch should not have affected that difference.
|
Mon 07 Jan 2008 09:42:07 PM UTC, comment #4:
on FreeBSD the situation changed, but is still incorrect. Instead of NIL I get:
%obj/NSFMTest
2008-01-07 22:23:23.036 NSFMTest[3373] size is 342919168
%df -k
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/ad0s3a 8925838 3682586 4529186 45% /
devfs 1 1 0 100% /dev
On NetBSD I get insstead:
strider: {19} obj/NSFMTest
2008-01-07 22:40:43.744 NSFMTest[29388] size is 1921449984
Filesystem 512-blocks Used Avail Capacity Mounted on
/dev/wd0a 37947292 10415000 25634928 28% /
The test program is still the same. I really don't know, maybe I'm wrong at intepreting the data?In both cases the ratio between indicated value and free blocks is about 75, but that makes no sense to me
|
Mon 07 Jan 2008 02:37:30 PM UTC, comment #3:
I added my suggested fix. Could you please give it a try on NetBSD.
As for the FreeBSD case you will need to supply the config.log file, so we are able to see, which interfaces could be found there.
|
Mon 07 Jan 2008 09:55:00 AM UTC, comment #2:
The documentation is pretty clear to me: the value can be bytes, blocks, you don't know: it is platform dependent.
My problem is that on NetBSD the value I get doesn't seem to be reasonable. As you see in my snippet it is netiher and I cannot relate it easily.
A further problem is that on FreeBSD: I get no value at all. nil.
|
Mon 31 Dec 2007 02:13:39 PM UTC, comment #1:
Could you please explain the change that you want to see?
GNUstep is currently using f_bavail to determine the available free blocks, would you like to see this replaced by f_bfree?
Or is that problem that the numbers you get from GNUstep don't match what you get via df? GNUstep tries to report bytes, perhaps the usage of f_bsize is rwrong and we should multiply by f_frsize. The documentation is not very clear on these two values.The old statfs only has f_bsize, which may be the reason why GNUstep uses this value.
No idea what goes wrong on FreeBSD you should try to get more information there.
|
Sun 30 Dec 2007 10:59:02 PM UTC, original submission:
using this example code:
NSFileManager *fm = [NSFileManager defaultManager];
NSDictionary *attributes = [fm fileSystemAttributesAtPath: @"/home"];
NSNumber *freefs = [attributes objectForKey: NSFileSystemFreeSize];
The documentaiton says this should return the free space "in an appropriate measure unit". Usually it is byte, but it could be blocks for example.
On NetBSD I get:
2007-12-31 00:00:13.346 NSFMTest[225] size is 2263040000
while free blocks are:
Filesystem 512-blocks Used Avail Capacity Mounted on
/dev/wd0a 37947292 10331604 25718324 28% /
conveniently expressed in 1k blocks:
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/wd0a 18973646 5165802 12859162 28% /
On FreeBSD the thing is even worse: freefs is nil. Nothing gets returned, as if the quantity coulnd-t be read or (according to comments inside NSFontManager.m) the path didn't exist.
|