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
