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

[Christian Schoenebeck <qemu_oss@crudebyte.com>]

On Donnerstag, 27. August 2020 16:01:07 CEST Matthew Wilcox wrote:
> On Thu, Aug 27, 2020 at 03:48:57PM +0200, Christian Schoenebeck wrote:
> > On Donnerstag, 27. August 2020 14:25:55 CEST Matthew Wilcox wrote:
> > > On Thu, Aug 27, 2020 at 02:02:42PM +0200, Christian Schoenebeck wrote:
> > > > What I could imagine as delimiter instead; slash-caret:
> > > >     /var/foo.pdf/^/forkname
> > > 
> > > Any ascii character is going to be used in some actual customer
> > > workload.
> > 
> > Not exactly. "/foo/^/bar" is already a valid path today. So every Linux
> > system (incl. all libs/apps) must be capable to deal with that path
> > already, so it would not introduce a tokenization problem.
> 
> That's exactly the point.  I can guarantee you that some customer is
> already using a file named exactly '^'.

You are contradicting yourself. Ditching the idea because a file "^" might 
exist, implies ditching your idea of "💩" as it might already exist as well.

> > > I suggest we use a unicode character instead.
> > > 
> > > /var/foo.pdf/💩/badidea
> > 
> > Like I mentioned before, if you'd pick a unicode character (or binary),
> > then each shell will map their own ASCII-sequence on top of that. Because
> > shell users want ASCII. Which would defeat the primary purpose: a unified
> > path resolution.
> 
> You misunderstood.  This was my way of telling you that your idea is shit.

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.

If you are concerned about not breaking anything: keep forks disabled.

Best regards,
Christian Schoenebeck