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

On Tue, Aug 11, 2020 at 04:36:32PM +0200, Miklos Szeredi wrote:

quoted

quoted

quoted

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

Currently substituting the body of a relative symlink in place of its name
results in equivalent pathname.

Except proc symlinks, that is.

 With your patch that is not just no longer
true, it's no longer true even when the symlink body does not contain that
/// kludge - it can come in part from the symlink body and in part from the
rest of pathname.  I.e. you can't even tell if substitution is an equivalent
replacement by looking at the symlink body alone.

Yes, that's true not just for symlink bodies but any concatenation of
two path segments.

That's why it's enabled with RESOLVE_ALT.  I've said that I plan to
experiment with turning this on globally, but that doesn't mean it's
necessarily a good idea.  The posted patch contains nothing of that
sort.

Thanks,
Miklos