O_XATTR support in FreeBSD?

[John Baldwin]

On Friday, September 05, 2014 04:24:02 PM Lionel Cons wrote:
> On 1 December 2013 23:05, Lionel Cons <lionelcons1972 at gmail.com> wrote:
> > On 27 November 2013 05:52, Tim Kientzle <tim at kientzle.com> wrote:
> >> On Nov 26, 2013, at 1:51 AM, Cedric Blancher <cedric.blancher at gmail.com> 
wrote:
> >>> 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.
> >> 
> >> There are quite a few alternative approaches for storing
> >> extended attributes in tar and pax files.
> > 
> > But this discussion is *not* about extended attributes, this
> > discussion is about Alternate Data Streams. Unfortunately the O_XATTR
> > discussion somehow started to cover the Linux "extended attribute
> > system", which is utterly useless in the intended use cases (as said,
> > no access through normal POSIX read(), write(), mmap(), no unlimited
> > size, no sparse data support (aka SEEK_HOLE, SEEK_DATA) etc etc).
> > 
> > Lionel
> 
> What is the status of O_XATTR (alias alternate data stream support) in
> FreeBSD? We run more and more into the trouble that these kind of
> streams are in use but cannot be accessed or processed on FreeBSD.

I don't think anyone is even looking at it.  I didn't quite follow the
earlier mail about this and some concrete examples probably would help.
Can you do 'open("/path/to/foo at forkname", O_XATTR)' to open the "forkname"
fork of the "/path/to/foo" file?

-- 
John Baldwin