Re: NSURL getResourceValue: for NSURLVolumeMaximumFileSizeKey returns nil
Re: NSURL getResourceValue: for NSURLVolumeMaximumFileSizeKey returns nil
- Subject: Re: NSURL getResourceValue: for NSURLVolumeMaximumFileSizeKey returns nil
- From: Benjamin Fleischer <email@hidden>
- Date: Sun, 16 Apr 2017 01:01:21 +0200
Hi Jim,
Is there anything we can do to work around this in the meantime? NSURLVolumeMaximumFileSize seems to work after adding support for _PC_FILESIZEBITS. However, so far we have not found a way to make FSGetVolumeParms() return the bSupports2TBFiles flag.
corservicesd calls vfsop_getattr multiple times but never with an active f_capabilities flag. This would explain why NSURLVolumeMaximumFileSize didn’t work before adding support for _PC_FILESIZEBITS.
Since FSGetVolumeParms() works for HFS volumes I assume there might be a way we can work around this. In particular, I'm interested in the specific conditions under which coreservicesd does not ask for the file system’s capabilities. It would be very helpful if you could share your findings.
Thanks,
Benjamin
> Am 15.04.2017 um 23:34 schrieb Jim Luther <email@hidden>:
>
> I think I might have found a path through the our code where this could happen. Please write a bug report against the "CoreServicesDaemon" component, version "X" (or put that in the bug report so it gets routed correctly).
>
> Getting a bug report from outside of Apple increases its chances of being addressed. Steps to reproduce the problem (even it the problem is intermittent) increase those chances even more.
>
> - Jim
>
>> On Apr 14, 2017, at 5:33 PM, Scott Talbert <email@hidden> wrote:
>>
>> Well, I may have found a partial answer to my question. I came across this (rather old) post from Quinn:
>> https://lists.apple.com/archives/Darwin-kernel//2007/Nov/msg00092.html
>>
>> It suggests that Finder calls the PBHGetVolParms() (replaced by FSGetVolumeParms()) and checks for the bSupports2TBFiles flag.
>>
>> Sure enough, even with the NSURL properties being reported correctly now, if I call FSGetVolumeParms() for my filesystem, the bSupports2TBFiles flag is not set.
>>
>> Now to try and figure this one out...the post further suggests that it's related to the VOL_CAP_FMT_2TB_FILESIZE bit as returned by getattrlist(). That bit is set correctly, but as I discovered while investigating the NSURL issue, I never saw a call to getattr() from coreservicesd, even when it should have fallen back to that when pathconf() was not implemented.
>>
>> On Fri, 14 Apr 2017, Scott Talbert wrote:
>>
>>> The problem is, this Finder error is only reproducible on two machines, out of perhaps several dozen using this filesystem. So, unfortunately, I don't have a set of easy steps to reproduce.
>>>
>>> On Fri, 14 Apr 2017, Jim Luther wrote:
>>>
>>>> At this point, I suggest you write a bug report with easy steps to reproduce the problem. If you file it against NSURL or CFURL, it'll get to the right place.
>>>> - Jim
>>>>> On Apr 14, 2017, at 11:49 AM, Scott Talbert <email@hidden> wrote:
>>>>> Sigh. Even after resolving the issue with the getResourceValue returns, I
>>>>> am still seeing "The item xyz can't be copied because it is too large for
>>>>> the volume's format" from Finder.
>>>>> Do you know the precise circumstances under which Finder will issue this
>>>>> error message? If not, is there a better place to ask about Finder?
>>>>> Thanks again for your help on this,
>>>>> Scott
>>>>> On Fri, 14 Apr 2017, Scott Talbert wrote:
>>>>>> There doesn't appear to be any similar user checks in getattr(). In fact, the only request I'm seeing to getattr() from the coreservicesd PID is for the filesystem uuid, and that happens before the request to pathconf() comes in. I don't see any calls to getattr() after the pathconf() request.
>>>>>> And yes, I understand about the return values from pathconf(). I was just suggesting coreservicesd might be doing something different based on the errno, but it sounds like it is not.
>>>>>> On Fri, 14 Apr 2017, Jim Luther wrote:
>>>>>>> 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
>
> _______________________________________________
> 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
_______________________________________________
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