bugGNUstep - Bugs: bug #21914, nsfilemanager has problems...

Group
 
 

bug #21914: nsfilemanager has problems reporting filesizes on freebsd

Submitter:  Riccardo Mottola <rmottola>
Submitted:  Sun 30 Dec 2007 10:59:02 PM UTC
   
 
Category:  Base/Foundation Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  CaS
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 20 Feb 2008 05:26:13 PM UTC, comment #19: 

seems to work here on freebsd

Riccardo Mottola <rmottola>
Group Member
Wed 20 Feb 2008 02:52:34 PM UTC, comment #18: 

Altered configure.ac to try to work around header dependencies on free bsd

Richard Frith-Macdonald <CaS>
Group Member
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.

Richard Frith-Macdonald <CaS>
Group Member
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.



Richard Frith-Macdonald <CaS>
Group Member
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.

Riccardo Mottola <rmottola>
Group Member
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

Riccardo Mottola <rmottola>
Group Member
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

Richard Frith-Macdonald <CaS>
Group Member
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

Riccardo Mottola <rmottola>
Group Member
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

Riccardo Mottola <rmottola>
Group Member
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?

Richard Frith-Macdonald <CaS>
Group Member
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

Riccardo Mottola <rmottola>
Group Member
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).

Richard Frith-Macdonald <CaS>
Group Member
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

Sebastian Reitenbach <buzzdee>
Group Member
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' ?

Richard Frith-Macdonald <CaS>
Group Member
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.

Fred Kiefer <FredKiefer>
Group Member
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

Riccardo Mottola <rmottola>
Group Member
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.

Fred Kiefer <FredKiefer>
Group Member
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.

Riccardo Mottola <rmottola>
Group Member
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.

Fred Kiefer <FredKiefer>
Group Member
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.

Riccardo Mottola <rmottola>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #14805:  main.m added by rmottola (1KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by buzzdee (Posted a comment)
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by FredKiefer (Posted a comment)
  • -email is unavailable- added by rmottola (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-02-20 rmottola StatusIn Progress Fixed
        Open/ClosedIn Test Closed
    2008-02-20 CaS Assigned toNone CaS
        Open/ClosedOpen In Test
    2008-02-18 CaS Summarynsfilemanager has problems reporting filesizes on several platforms nsfilemanager has problems reporting filesizes on freebsd
    2008-01-15 rmottola Attached File- Added main.m, #14805
    2008-01-07 FredKiefer StatusNone In Progress

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code