Date: Tue, 26 Nov 2013 02:19:08 -0800 From: Jordan Hubbard <jordan.hubbard@gmail.com> To: Cedric Blancher <cedric.blancher@gmail.com> Cc: Freebsd hackers list <freebsd-hackers@freebsd.org>, Richard Yao <ryao@gentoo.org>, Pedro Giffuni <pfg@freebsd.org>, Rick Macklem <rmacklem@uoguelph.ca> Subject: Re: O_XATTR support in FreeBSD? Message-ID: <C936E1CA-9F83-4992-BFA2-073CF8543BC8@mail.turbofuzz.com> In-Reply-To: <CALXu0UfEQD2y6m5irGQRms=6bY8H854v0Wu9_96JpL4w6wntcg@mail.gmail.com> References: <BC41DB59-5868-432D-9452-00F420934E12@mail.turbofuzz.com> <718836647.19911209.1385302696963.JavaMail.root@uoguelph.ca> <CALXu0UfEQD2y6m5irGQRms=6bY8H854v0Wu9_96JpL4w6wntcg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 26, 2013, at 1:51 AM, Cedric Blancher <cedric.blancher@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=92t know if I=92d go so far as to say =93you do not need more = syscalls=94; 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=92re also glossing over ACLs and where they get to live. I don=92t = know if Robert and friends have stuck them in a separate namespace on FreeBSD or if = they=92re 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=92re 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=92t 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 =93sidecar=94 files may strike all concerned as grotty hacks, = and they sort of ARE, but they=92re also the only fully functional, = work-in-pretty-much-all=20 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=92re serializing a file across *any* streaming serialization protocol, you = sidecar it and if the other side doesn=92t 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C936E1CA-9F83-4992-BFA2-073CF8543BC8>