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

[Christian Schoenebeck <qemu_oss@crudebyte.com>]

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.

The caret character is not reserved by any filesystem either:
https://en.wikipedia.org/wiki/Filename

The only change a caret delimiter would bring, is a very minor change in 
semantic: apps would no longer be allowed to create dirs/files named exactly 
"^". But I find that a very small restriction compared to the negative impact 
of other delimiter options, i.e.:

	touch /some/where/^          # error if forks enabled, OK otherwise
	touch /some/where/^whatever  # always OK

So if you have apps that need to access dirs/files called *exactly* "^", that 
would be easy to fix. And if you don't want to, you just keep kernel's support 
for forks disabled and preserve old semantic of "^".

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

Then even if you'd pick unicode, that would raise new questions and problems; 
e.g. utf-8, utf-16, utf-32? Character normalization required? How do you 
ensure each layer will use the same encoding?

Best regards,
Christian Schoenebeck