Scott wrote a good bug report so I have something to work with. Reproducible problem == much easier to figure out.
I'll let you know what I find, and let you know if there's a work around. - Jim > On Apr 15, 2017, at 4:01 PM, Benjamin Fleischer <flei...@gmail.com> wrote: > > 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 <luthe...@apple.com>: >> >> 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/fleiben%40gmail.com >> >> This email sent to flei...@gmail.com > _______________________________________________ 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
