On Jul 29, 2005, at 12:37 PM, Brian Bergstrand wrote:
As Quinn suggested, start with fs_usage and look for errors. If getattrlist is failing, take a look at your getattr handler and check that VATTR_ALL_SUPPORTED() returns true against the vnode_attr that you're returning. The VFS will synthesise some fields, but getattrlist(2) will fail if an attribute can't be returned (unlike the VFS-level interface).
The problem is we don't support certain things. Is it okay to fill in 0 for fields that we don't support?
No; as a general rule if you don't support it, don't return anything. In some cases though, you can make a better guess at a sensible pseduo-value than the VFS, and in that case you're better off faking it up yourselves.
In particular, va_acl, va_encoding, va_uuuid, and va_guuid, and va_nchildren? Looking at getattrlist in the kernel, it looks like it should ignore or synth these values (although va_nchildren defaults to va_nlink - 2 and we always return 1 for va_nlink, so that would result in an underflow for va_nchildren).
va_acl, va_uuud, va_guuid will never be asked for unless you advertise that you support extended security. va_encoding is defaulted by the VFS. va_nchildren assumes that you do the historical BSD VFS thing and return va_nlink set to the total entry count for directories (since directories are not permitted to have more than one link, they overloaded this many years ago).
I ran fs_usuage, and it looks like getdirentries is return EINVAL for some reason, didn't see any errors elsewhere. So at least I have a place to start now.