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
