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
