On Thu, Nov 21, 2019 at 3:53 AM Raimo Niskanen <[email protected]> wrote: > > On OpenBSD 6.6 amd64 patch 006, i get peculiar results from readlink(1) > with arguments -f with a symlink to / > > $ readlink -f / > / > > $ ln -s / test; readlink -f test; rm test > readlink: test: Is a directory > > $ readlink -f /. > / > > $ ln -s /. test; readlink -f test; rm test > / > > I have tried with many arguments to readlink -f and the result seems to be > the same for a direct argument as for a symbolic link with the same > content. Except for a symbolic link to exactly / > > Bug|Glitch|Feature?
It's a bug -> which I just fixed. Details: So what happened is we used to have a non-posix realpath behavior that would return a realpath to a nonexistant file -> as such I was calling namei in the kernel with LOCKPARENT (unless it was / where you can't do this) the problem I had was the symlink to '/' was still requesting LOCKPARENT with no "parent" to lock -> and failing with EISDIR as you noticed. The fix is that we just no longer need this dance, and we don't need to LOCKPARENT or not... So it now works with what I committed yesterday > > I also noticed that if readlink -f is told to traverse above / it this that > is ok. Would that merit an error instead? > > $ readlink -f /var > /var > $ readlink -f /../var > /var > $ readlink -f /../../var > /var This isn't a bug, it's how it's supposed to work. ".." from / is actually still / . if you have a look at /usr/src/regress/sys/kern/realpath you'll see the regression tests explicitly test for this case working. > > Best regards > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB >
