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 <s...@techie.net> 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 <s...@techie.net> 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 <s...@techie.net> >>>>>> 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 >>>>>> <s...@techie.net> 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 (Filesystem-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/filesystem-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
