O_XATTR support in FreeBSD?

[Jordan Hubbard]

On Nov 23, 2013, at 2:53 PM, Rick Macklem <rmacklem at uoguelph.ca> wrote:

> Interestingly, FreeBSD has a VOP_OPENEXTATTR() but no syscall
> that uses it nor support for it in ZFS. (I'm just guessing it
> was intended for an openat(2) syscall at some time?)
> Btw Cedric, if you had mentioned "subfiles" or "fork files" in your
> subject line, you might have gotten a better answer. I, for one,
> didn't know what O_XATTR is. I also always get confused w.r.t. what
> to call these beasts. (NFSv4 calls the named attributes.)
> 
> Btw, apps can use extended attributes (the limited sized
> atomically stored/read kind). They aren't just for
> storing ACLs.

Sigh.  Extended Attributes. :-/

I guess I’ll raise my head in this discussion.  They’ve certainly been the bane of my existence for long enough!

First, supporting EAs properly really involves multiple levels of the Unix command and library stack.

The filesystem can support them natively, sure, but that’s actually somewhat optional since you can always (cough cough) stick them in a side-store if the rest of the stack cooperates.  That’s where the awesome AppleDouble files came from (“._weirdfile" corresponding to “weirdfile") which remain useful even after filesystems like HFS/ZFS/UFS became EA-aware natively because there’s always those foreign data stores to talk to (some early AFP/CIFS/NFS mount, for example) and the fact that you still need to *serialize* the dang things into tar / cpio / zip / ??? files as well as across network replication with tools like rsync.  What good is an EA, much less an ACL that’s been stored in an EA, if it gets stripped off the first time you tar up a directory and extract it somewhere else?

So I wouldn’t start with NFSv4 or ZFS if I was asking the question.  I would start with libc and ask if it had anything similar to copyfile(3) so that the tools above it could start actually supporting those attributes on a *practical* basis! :)

- Jordan