Re: NSURL getResourceValue: for NSURLVolumeMaximumFileSizeKey returns nil
Re: NSURL getResourceValue: for NSURLVolumeMaximumFileSizeKey returns nil
- Subject: Re: NSURL getResourceValue: for NSURLVolumeMaximumFileSizeKey returns nil
- From: Scott Talbert <email@hidden>
- Date: Fri, 14 Apr 2017 11:56:21 -0400 (EDT)
OK, I think I finally have some idea of what's going on...
After I added _PC_FILESIZEBITS support, in the cases where
NSURLVolumeMaximumFileSize was still being reported incorrectly, it was
because FUSE was denying the pathconf() request from coreservicesd. FUSE
has some logic for blanket denying requests, and in this case the request
was denied because it was from the root user and not the user who mounted
the filesystem. I don't understand the purpose of trying to deny requests
from root, so when I removed this check, things work correctly.
Now, I still don't understand why coreservicesd isn't falling back to
getattrlist() when the pathconf() request fails. Perhaps depending on the
type of error from pathconf(), it doesn't go further to getattrlist()?
Scott
On Thu, 13 Apr 2017, Jim Luther wrote:
OK -- I don't have a clue.
If you have a reproducible case that you can provide steps for, please
file a bug report against the component "CFURL | all", and I can take a
look at it.
- Jim
On Apr 13, 2017, at 3:31 PM, Scott Talbert <email@hidden> wrote:
On Thu, 13 Apr 2017, Jim Luther wrote:
You could test my theory by writing a program that:
• listens for kNotifyVFSMount BSD notifications (see man 3 notify and the
notify.h and notify_keys.h headers)
• when it gets the kNotifyVFSMount notification, call getmntinfo(3) to get
the array of statfs structures for each currently mounted file system.
• finds your file system in the array and pass its path (f_mntonname) to
the getMaxFileSize() function and see what it does.
If the statfs struct from getmntinfo() for your file system doesn't look
correct, check to make sure your file system's data for the vfs_statfs
callback is initialized before your file system's vfs_mount callback
returns. One way to do that is to have your file system's vfs_mount code
call your file system's vfs_statfs callback (that's the approach I took in
the WebDAV file system long ago when I wrote it).
If getattrlist() fails or returns the wrong value, check the code for your
file system's vfs_getattr callback to make sure it is prepared to handle
requests before your file system's vfs_mount callback returns. Look at
where the vfs_getattr callback handles f_capabilities.
Again in this case, getMaxFileSize() returns the correct value, but the NSURL call does not:
BLAH f_bsize:4096 f_iosize:4096 f_blocks:0 f_bfree:0 f_bavail:0 f_files:0 f_ffree:0 f_fsid[0]:1258291282 f_fsid[1]:51 f_owner:501 f_type:51 f_flags:26 f_fssubtype:0 f_fstypename:osxfuse f_mntonname:/Users/stalbert/hello f_mntfromname:hello_ll@osxfuse0
BLAH getMaxFileSize ret=0 maxFileSize=9223372036854775807
2017-04-13 18:16:50.982 notify[73589:1525216] NSURLVolumeMaximumFileSize: 1 (null) (null)
Also, you can add _PC_FILESIZEBITS support to your file
system's vnop_pathconf callback so that pathconf() with _PC_FILESIZEBITS
will return a more exact value. VOL_CAP_FMT_2TB_FILESIZE is the "big dumb
hammer" fallback if we cannot get a value from pathconf().
Interestingly, if I do that, some FUSE filesystems start reporting the correct size with NSURLVolumeMaximumFileSize, but some continue to report TRUE, nil, nil as before.
Scott
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden