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 protected]> 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 protected]> 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 protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/filesystem-dev/archive%40mail-archive.com
This email sent to [email protected]
