O_XATTR support in FreeBSD?

[Jordan Hubbard]

On Nov 26, 2013, at 1:51 AM, Cedric Blancher <cedric.blancher at gmail.com> wrote:

> 1. You do not need more syscalls. Solaris uses the plain openat()
> syscall for this, with the O_XATTR flag passed to the normal
> open()/openat() flags to open a named attribute. Likewise read(),
> write(), mmap() etc work, too.

I don’t know if I’d go so far as to say “you do not need more syscalls”;
there are additional functions for manipulating EAs that go well beyond
the Solaris extensions to the directory and file I/O functions.  Assuming you
want to be able to get/set as well as enumerate or remove EAs, then
you might just as well add getxattr(2), listxattr(2), removexattr(2), setxattr(2)
too and follow the herd (Linux and OS X, so far).

We’re also glossing over ACLs and where they get to live.  I don’t know if Robert
and friends have stuck them in a separate namespace on FreeBSD or if they’re
in system-protected EAs, as they are in OS X, but ACL preservation across
serialization / deserialization is just as important as it is for EAs.

> 5. Support for tar and pax is already there. Its described in
> Solaris's fsattr man page, they use a extended header with filename
> /dev/null (to prevent older tar versions from tripping over the new
> headers) and then have a named attribute header which describes the
> attributes names and flags.

This approach gets uglier when you try to apply to tools like rsync or scp -
now we’re going  to version their protocols?   I think this was the wrong
approach, basically.  Now there are multiple semi-compatible versions of
tar and pax on Solaris, and they didn’t do anything for zip/bzip/gzip (what
happens when you bzip2 a file with EAs and then unbzip it again?  What
if that file is on a remote NFSv3 share?).

Again, the “sidecar” files may strike all concerned as grotty hacks, and
they sort of ARE, but they’re also the only fully functional, work-in-pretty-much-all 
situations solution for these scenarios.  If the underlying filesystem supports
EAs, you just copy it from old to new or you stick it in the sidecar file.  If you’re
serializing a file across *any* streaming serialization protocol, you sidecar it
and if the other side doesn’t support EAs, fine, the sidecar file remains there
intact and no data-loss has occurred.  If it does, it simply combines the file
and sidecar files together and they disappear again.

- Jordan