-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extended attributes of symlinks #31
Comments
Additionally, I did a test on macOS to find file creation time of a symlink using |
Yeah, something's going on here. All records (files/folders/links/etc) should have hfsfuse.record.date_created available at least as this comes from the record structure itself (the same is technically true of FinderInfo but by convention that one isn't listed as an xattr if it's empty.) I'll take a look. |
This ended up being pretty simple. The Linux kernel actually disallows user extended attributes on anything but regular files. I think the only way around this is for hfsfuse_listxattr to stop returning attribute names under Linux for things that aren't regular files. At least that info will still be available via hfsdump. Using a different non-user namespace (like I pushed the former change in 2ab526c so this should be resolved if you pull master. |
I would suggest allowing it for directories as well since those are allowed to have user extended attributes in Linux. As for the possibility of using a non-user namespace, I would suggest making a mount option for that or just having it by default. Since the program runs as root and is involved with filesystems I would imagine it better to use a non-user namespace, but this is up to you of course. |
You're right thanks, directories should be included in the allowed types. That's now fixed. Unfortunately with custom namespaces it seems that user tools (including rsync) are unable to copy these even for regular files, which is kind of expected, but makes this hard to do in a way that's not confusing to use (e.g. only symlinks get a custom namespace) or results in unexpectedly missing something when moving data around. I considered while working on xattr support a bit ago adding an xattr mount mode similar to |
I found that it is possible if you use "security", "system", or "trusted" namespaces which all have different purposes, mentioned on the same man page you sent earlier. On Linux the program must run as root or have
Notably, the only difference to hfsfuse's use-case would be the "ordinary processes should not have access" part mentioned at the end. It would be preferable for them to have access to these. Example usage of the I also set this up as a prefix in my local |
I tried a few combinations myself, it seems to vary a lot between the 4 (+ custom) as far as what can be read vs written by root and non root and the type of file. Otherwise I'm still a bit split on letting this be changed with a runtime option vs coming up with another interface for accessing these, but I'd like to have something to cover these inconsistencies. I wonder how other Linux filesystem drivers even outside of FUSE handle this, since HFS+ is definitely not the only filesystem that supports extended attributes on symlinks. |
Yes I would say a Makefile option makes sense. I haven't used config.mak (is it autotools-related?) |
For hfsfuse it's just something for convenience to rebuild without specifying options to make every time. It can be created with |
After experimenting with some more involved ways of displaying these on the filesystem, I decided to go with the simplest and just add an option to mount with symlinks as regular files as a fallback means for viewing these in c528f3c. Between this and the namespace option there are now at least a few alternative ways to access these, so I'll go ahead and close this. Thanks again for these reports. |
Running
getfattr --no-dereference -d -m '' -- file
, wherefile
is the symlink to test and it has no attributes, will output the following:I think the correct behavior should be no output. Symlinks are allowed to have extended attributes (I used xattr on macOS to test this), but this particular symlink doesn't have the above attributes. Maybe these attribute names are somehow built into hfsfuse as attribute names it checks for, like in
hfsfuse_getxattr_offset
. Looking at the code forgetfattr
, hfsfuse might be returning these attributes as built-in attribute names, but they return ENODATA when queried for an attribute value.lgetxattr
, when called onuser.com.apple.FinderInfo
, returns ENODATA since there is no such attribute on the symlink anyway, butllistxattr
is returning those two attributes extraneously.The text was updated successfully, but these errors were encountered: