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
