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

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

Dan
-- 
Dan Shelton - Cluster Specialist Win/Lin/Bsd