Re: xattr names for unprivileged stacking?

[Dave Chinner <david@fromorbit.com>]

On Thu, Aug 13, 2020 at 11:01:36AM +0200, Christian Schoenebeck wrote:
> On Mittwoch, 12. August 2020 16:33:23 CEST Dr. David Alan Gilbert wrote:
> > > On macOS there was (or actually still is) even a quite complex API which
> > > separated forks into "resource forks" and "data forks", where resource
> > > forks were typically used as components of an application binary (e.g.
> > > menu structure, icons, executable binary modules, text and translations).
> > > So resource forks not only had names, they also had predefined 16-bit
> > > type identifiers:
> > > https://en.wikipedia.org/wiki/Resource_fork
> > 
> > Yeh, lots of different ways.
> > 
> > In a way, if you had a way to drop the 64kiB limit on xattr, then you
> > could have one type of object, but then add new ways of accessing them
> > as forks.
> 
> That's yet another question: should xattrs and forks share the same data- and 
> namespace, or rather be orthogonal to each other.

Completely orthogonal. Alternate data streams are not xattrs, and
xattrs are not ADS....

Indeed, most filesystems will not be able to implement ADS as
xattrs. xattrs are implemented as atomicly journalled metadata on
most filesytems, they cannot be used like a seekable file by
userspace at all. If you want ADS to masquerade as an xattr, then
you have to graft the entire file IO path onto filesytsem xattrs,
and that just ain't gonna work without a -lot- of development in
every filesystem that wants to support ADS.

We've already got a perfectly good presentation layer for user data
files that are accessed by file descriptors (i.e. directories
containing files), so that should be the presentation layer you seek
to extend.

IOWs, trying to use abuse xattrs for ADS support is a non-starter.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com