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

[Christian Schoenebeck <qemu_oss@crudebyte.com>]

On Donnerstag, 27. August 2020 16:44:52 CEST Al Viro wrote:
> > 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.
> 
> > If you are concerned about not breaking anything: keep forks disabled.
> 
> s/disabled/out of tree/
> 
> One general note: the arguments along the lines of "don't enable that,
> then" are either ignorant or actively dishonest; it really doesn't work
> that way, as we'd learnt quite a few times by now.  There's no such
> thing as "optional feature" - *any* feature, no matter how useless,
> might end up a dependency (no matter how needless) of something that
> would force distros to enable it.  We'd been down that road too many
> times to keep pretending that it doesn't happen.

Well, it could be an option per mounted fs, but I know -> NAK.

On Donnerstag, 27. August 2020 18:29:35 CEST 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?

Built-in path resolution would be nice, but it won't be a show stopper for 
such common utils if not. For instance on Solaris there is:

runat <filename> <cmd> ...

which works something like fchdir(); execv(); you loose some flexibility, but 
in practice still OK.

> 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).

It seems to be both a file & dir feature on all systems that have that 
concept. So people would expect it for dirs on Linux as well.

Best regards,
Christian Schoenebeck