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

Christian Schoenebeck
2020-08-27T14:11:31Z

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