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 Wed, Sep 10, 2025 at 2:04 PM Lionel Cons <lionelcons1972@gmail.com> wrote:
>
> On Tue, 9 Sept 2025 at 14:36, Joshuah Hurst <joshhurst@gmail.com> wrote:
> >
> > On Thu, Sep 4, 2025 at 8:25 AM Roland Mainz <roland.mainz@nrubsig.org> wrote:
> > >
> > > On Wed, Sep 3, 2025 at 6:34 PM Cedric Blancher
> > > <cedric.blancher@gmail.com> wrote:
> > > [Please keep me in the CC:, I do not get emails from the freebsd-hackers@ list]
> > > >
> > > > On Tue, 2 Sept 2025 at 23:12, Rick Macklem <rick.macklem@gmail.com> wrote:
> > > > >
> > > > > On Tue, Sep 2, 2025 at 11:29 AM Dan Shelton <dan.f.shelton@gmail.com> wrote:
> > > > > >
> > > > > > On Sat, 30 Aug 2025 at 12:54, Lorenzo Salvadore <salvadore@freebsd.org> wrote:
> > > > > > > The top level system call interface is open(2)/openat(2) with the new
> > > > > > > O_NAMEDATTR flag (called O_XATTR on Solaris).
> > > > > > >
> > > > > > > Most of the work has been committed to FreeBSD’s main for FreeBSD 15. Once the
> > > > > > > ZFS patch makes it through review and gets pulled into OpenZFS, the ZFS and
> > > > > > > NFSv4 support should work. There are also a couple of manual pages currently
> > > > > > > under review in phabricator.
> > > > > > >
> > > > > > > The main thing left to do is update libarchive/tar so that large extended
> > > > > > > attributes can be archived/retrieved. (The current FreeBSD extended attribute
> > > > > > > mechanism is supported by libarchive, but will have size constraints.)
> > > > > >
> > > > > > 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".
- 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).
- 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.)

rick

>
> I agree.
>
> Lionel
>