On Tue, Aug 11, 2020 at 4:42 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > On Tue, Aug 11, 2020 at 04:36:32PM +0200, Miklos Szeredi wrote: > > > > > - 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
