Re: file forks vs. xattr (was: xattr names for unprivileged stacking?)

[Matthew Wilcox <willy@infradead.org>]

On Thu, Aug 27, 2020 at 05:29:35PM +0100, Dr. David Alan Gilbert wrote:
> * Al Viro (viro@zeniv.linux.org.uk) wrote:
> > On Thu, Aug 27, 2020 at 04:23:24PM +0200, Christian Schoenebeck wrote:
> > 
> > > Be invited for making better suggestions. But one thing please: don't start 
> > > getting offending.
> > > 
> > > No matter which delimiter you'd choose, something will break. It is just about 
> > > how much will it break und how likely it'll be in practice, not if.
> > 
> > ... which means NAK.  We don't break userland without very good reasons and
> > support for anyone's pet feature is not one of those.  It's as simple as
> > that.
> 
> I'm curious how much people expect to use these forks from existing
> programs - do people expect to be able to do something and edit a fork
> using their favorite editor or cat/grep/etc them?
> 
> I say that because if they do, then having a special syscall to open
> the fork wont fly; and while I agree that any form of suffix is a lost
> cause, I wonder what else is possible (although if it wasn't for the
> internal difficulties, I do have a soft spot for things that look like
> both files and directories showing the forks; but I realise I'm weird
> there).

I also have fond memories of !SquashFS but the problem is that some
people want named streams on _directories_, which means that these
directories need to be both directories-of-files and directories-of-streams.
That's harder to disambiguate.

I think providing two new tools (or variants on existing tools) --
streamcat and streamls should be enough to enable operating on named
streams from the command line.  If other tools want to provide the ability
to operate on named streams directly, that would be up to that tool.