Re: Renaming O_NAMEDATTR to O_NAMEDSTREAMS Re: Size of "alternate data streams"/"resource forks" / O_NAMEDATTR Re: FreeBSD Status Report - Second Quarter 2025

On Sat, Sep 13, 2025 at 12:05 PM Vadim Goncharov
<vadimnuclight@gmail.com> wrote:
>
> On Wed, 10 Sep 2025 15:06:47 -0700
> Rick Macklem <rick.macklem@gmail.com> wrote:
>
> > > > > > > > 1. There are no size constraints. The main problem is different:
> > > > > > > > SUN's original name is both a misnomer, and was hijacked by
> > > > > > > > Linux to stuff in their broken clone of Windows extended
> > > > > > > > attributes.
> > > > > > > >
> > > > > > > > The O_NAMEDATTR/O_XATTR files are in fact "alternate data
> > > > > > > > streams", like on Windows, macOS (which calls them resource
> > > > > > > > forks), and mainframe operating systems.
> > > > > > > > They can have unlimited size (like the "main" data stream), and
> > > > > > > > can even be sparse (SEEK_HOLE&friends). These are very different
> > > > > > > > beats from "extended attributes".
> > > > > > > >
> > > > > > > > Background:
> > > > > > > > Early versions of Windows started with EA (extended attributes),
> > > > > > > > and then Windows NT4 adopted alternate data streams as a
> > > > > > > > superior super set of the EA. Windows just couldn't get rid of
> > > > > > > > the EAs, so they (and their evil Linux xattr clone) and their
> > > > > > > > limitations keep haunting us.
> > > > > > > >
> > > > > > > > Funny is, EAs in Windows are nowadays just emulated via
> > > > > > > > alternate data streams (stream "$EA" is the index, stream
> > > > > > > > "$EA_INFORMATION" has the raw data).
> > > > > > > >
> > > > > > > > 2. Look at Solaris tar, which can handle unlimited size of
> > > > > > > > O_XATTR streams
> > > > > > > It might be possible to put Solaris tar (from OpenSolaris) in
> > > > > > > ports. I'll put it on my (currently rather long) todo list, unless
> > > > > > > someone else is inspired
> > > > > > > to look at it?
> > > > > > >
> > > > > > > As for libarchive, there are two problems:
> > > > > > > - The way it is structured, it generates a linked list of a file's
> > > > > > > extended attributes.
> > > > > > >   As such, it is possible for very large ones to run into malloc()
> > > > > > > failures (aka ENOMEM).
> > > > > > >   To fix this would be a major re-write of libarchive, so I do not
> > > > > > > see that happenning.
> > > > > > > - The other is that it currently uses
> > > > > > > extattr_get_file/extattr_set_file, which copies the
> > > > > > >   entire attribute in one syscall. This actually works for ZFS
> > > > > > > locally, but will not work
> > > > > > >   for NFSv4.2 because there is a limit (currently a little over
> > > > > > > 1Mbyte) on RPC message
> > > > > > >   size.
> > > > > > >   --> This should be fixable via a patch that replaces the above
> > > > > > > syscalls with loops
> > > > > > >        on read/write for file systems that support named
> > > > > > > attributes. This is already on my todo list.
> > > > > >
> > > > > > I think the problem here is that people think O_XATTR/O_NAMEDATTRS
> > > > > > are "attributes". Which implies a short amount of data, which is
> > > > > > ABSOLUTELY NOT THE CASE!!
> > > > > >
> > > > > > Maybe O_NAMEDATTR and O_XATTR should be renamed to O_NAMEDSTREAMS
> > > > > > (plural!), as a clear and present warning that this stuff can store
> > > > > > lots of data?
> > > > >
> > > > > I like the idea, because it fixes the problem that the
> > > > > |O_ATTR|/|O_NAMEDATTR| are treated like attributes, while SUN's
> > > > > intention was to implement "Alternate Data Streams" (which is a
> > > > > superset of "extended attributes" as seen in Win32 EA and Linux XATTR,
> > > > > but with none of their limitations and problems) for Windows, MacOS,
> > > > > VMS and mainframe OS support.
> > > > >
> > > > > Re Plural: NO, please read openat(2): You open ONE named (attribute)
> > > > > stream by passing this flag and the name, or the index (dir) by
> > > > > passing "." as name. One attribute == Singular.
> > > >
> > > > Please also update the related #defines:
> > > > 1. for openat()
> > > > O_NAMEDSTREAM
> > > >
> > > > 2. for pathconf()
> > > > _PC_NAMEDSTREAM_ENABLED
> > > > _PC_NAMEDSTREAM_EXISTS
> > > >
> > > > That is actually a naming convention better than XATTR.
> > Well, I've been trying to ignore this, but I guess I have to respond...
> > (Here's some rather random comments.)
> > - The bike shed is already painted green and the paint is dry.
> >   I do not see any reason to repaint it blue.
> > - As others have noted, every vendor has used a different name
> >   for this mechanism.
> >   The only place I am aware of where a standards document
> >   describes them is the NFSv4 RFCs and these documents
> >   call them "named attribute".
> > - I'm not a Windows guy and when I read "stream" I think of
> >   the SVR4 mechanism for handling network connections,
> >   which makes me shy of "namedstream".
>
> Fortunately, SVR4 were dead already in previous century. We may safely
> forget them. While being non-Windows guy, the NTFS is very good designed and
> deserves knowledge about it's format at least in tutorial level (ReiserFS
> tried to achieve same flexibility). They still call everything pertaining to
> file as "attributes", though - so those are just several $DATA attributes (in
> addition to other attributes, such as ACLs), default one (vast majority of
> regular files) just has empty name.
>
> > - I chose a name other than "extended attribute" (which is
> >   what Solaris calls it) because FreeBSD already uses
> >   extended attribute for another mechanism (the one that
> >   I think originated in SGI Irix and is in Linux).
>
> Yes, in NTFS attribute $EA could be one of them.
>
> > - If you think Oracle is going to change O_XATTR to some
> >   other name, well I'd be really surprised if they did.
> >   (I thought Solaris was on life support at this time.)
> >
> > FreeBSD is now in "slush" for the FreeBSD15 release,
> > which means commits are supposed to be focused on
> > bugfixes and I do not see renaming these as bugfixes.
> >
> > If I see a groundswell of support for the name change
> > by what I will refer to as FreeBSD users that post
> > comments regularly, I will consider doing it after
> > the FreeBSD15 release goes out.
> > (Sorry, but from what I have seen, the list of people posting
> > to this thread all appear to be somehow related to
> > the Windows NFSv4.1 client and not people who
> > have been using/contributing to FreeBSD for years.
> > This doesn't meant your opinions are not valid, but
> > I'd like to see support for this name change include
> > others outside your group, since I think it is basically
> > silly. If someone wants to use this mechanism they
> > will use it, whatever it happens to be called.)
>
> I think we are discussing adding an additional name as alias, not a true
> renaming?
I thought they were asking for an actual renaming. And I didn't think
O_NAMEDSTREAMS exists anywhere in the Windows APIs, so
having an alias for it helps how??

rick

>
> --
> WBR, @nuclight