On Tue, Aug 11, 2020 at 4:31 PM Al Viro [off-list ref] wrote:

On Tue, Aug 11, 2020 at 04:22:19PM +0200, Miklos Szeredi wrote:

quoted

On Tue, Aug 11, 2020 at 4:08 PM Al Viro [off-list ref] wrote:

quoted

On Tue, Aug 11, 2020 at 03:54:19PM +0200, Miklos Szeredi wrote:

quoted

On Wed, Aug 05, 2020 at 10:24:23AM +0200, Miklos Szeredi wrote:

quoted

On Tue, Aug 4, 2020 at 4:36 PM Miklos Szeredi [off-list ref] wrote:

quoted

I think we already lost that with the xattr API, that should have been
done in a way that fits this philosophy.  But given that we  have "/"
as the only special purpose char in filenames, and even repetitions
are allowed, it's hard to think of a good way to do that.  Pity.

One way this could be solved is to allow opting into an alternative
path resolution mode.

E.g.
  openat(AT_FDCWD, "foo/bar//mnt/info", O_RDONLY | O_ALT);

Proof of concept patch and test program below.

Opted for triple slash in the hope that just maybe we could add a global
/proc/sys/fs/resolve_alt knob to optionally turn on alternative (non-POSIX) path
resolution without breaking too many things.  Will try that later...

Comments?

Hell, NO.  This is unspeakably tasteless.  And full of lovely corner cases wrt
symlink bodies, etc.

It's disabled inside symlink body resolution.

Rules are simple:

 - strip off trailing part after first instance of ///
 - perform path lookup as normal
 - resolve meta path after /// on result of normal lookup

... and interpolation of relative symlink body into the pathname does change
behaviour now, *including* the cases when said symlink body does not contain
that triple-X^Hslash garbage.  Wonderful...

Can you please explain?

Thanks,
Miklos