| Maybe FUSE is blocking more than pathconf(). That's not my code to debug.
And yes, coreservicesd is running as the super user.
From man pathconf:
RETURN VALUES If the call to pathconf or fpathconf is not successful, -1 is returned and errno is set appropriately. Otherwise, if the variable is associated with functionality that does not have a limit in the system, -1 is returned and errno is not modified. Otherwise, the current variable value is returned.
So as the code I sent showed, we're checking the result against -1. On Apr 14, 2017, at 8:56 AM, Scott Talbert < email@hidden> wrote:
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
|