This patch adds support for the extended attribute operations to fuse.
It has been tested minimally with GlusterFS.
This patch adds extended attribute support to fuse. I need access
to some extended attributes in GlusterFS for my pNFS server work.
I don't know if any other fuse file systems support extended attributes?
For what it's worth, this patch seems to work when used with the net/s3ql filesystem. It has a unique method of communicating with the running daemon: it gets/sets extended attributes on a hidden control file in the mounted filesystem.
I've added Ken, since he also had a patch that added extended attribute support to fuse.
His patch actually worked for the "lsextattr" case, which is broken in this one.
The debate was that his patch prepended "system." or "user." to the extended
attribute name. That didn't work for my GlusterFS case, since it had extended
attribute names that didn't start with "system." or "user.".
Dan, does your filesystem use attribute names that start in "system." or "user."?
A compromise might be to prepend "user." for the NAMESPACE_USER, but leave
the names as specified for NAMESPACE_SYSTEM?
I've added Ken, since he might be interested in resurrecting his patch or maybe
we can merge them?
Looking at the s3ql server code, it seems to expect unprefixed names for its control operations, but does have checks for specific names in the system namespace ( https://bitbucket.org/nikratio/s3ql/src/release-2.22/src/s3ql/fs.py#fs.py-201 ). So I'd say that it currently expects the control attribute names to not be prefixed with "user." .
The linux manpages seem to imply that namespaces are required, though ( "Attribute names are null-terminated strings. The attribute name is always specified in the fully qualified namespace.attribute form" ), so it sounds like there's insufficient validation in the Linux kernel, and the s3ql code is currently relying on undefined behaviour. It looks like s3ql could easily be patched to move those into the user namespace if necessary.