public inbox for goredo-devel@lists.cypherpunks.ru
Atom feed
From: Sergey Matveev <stargrave@stargrave•org>
To: goredo-devel@lists.cypherpunks.ru
Subject: Re: Resolving paths within symlinked dirs targets)
Date: Fri, 22 Apr 2022 12:27:19 +0300 [thread overview]
Message-ID: <YmJ1AoZ7gcXKsU4a@stargrave.org> (raw)
In-Reply-To: <2243313a-6e81-27c1-af2d-7cbb8e5993d9@jnboehm.com>
[-- Attachment #1: Type: text/plain, Size: 2363 bytes --]
Greetings!
*** Jan Niklas Böhm [2022-04-17 22:37]:
>From what I understand the issue is that the absolute path is converted to a
>relative path, which is relative to the proper directory. On the other
>hand, the symlink then has a different nesting depth and resolving the
>relative path from the symlinked directory will point to a non-existent
>file; hence the target being ood.
Yes, everything is right.
>I am not entirely sure on what would be the
>best approach in order to correct this behavior, maybe the cwd can be
>resolved through the file system prior to checking for ood targets.
Actually initially goredo used to resolve its "physical" (pwd -P) path
to the current directory. But one of its users gave very good example
where it makes things very inconvenient in practice: for example in
FreeBSD /home/user is actually a symlink to /usr/home/user by default.
That is why pwd -P will return paths like that, when located in /home/user:
../../../../../../home/user/docs/3rd/goredo/all.do
../../../../../../home/user/docs/3rd/goredo/default.do
../../../../../../home/user/docs/3rd/default.do
../../../../../../home/user/docs/default.do
../../../../../../home/user/default.do
../../../../../../home/default.do
../../../../../../default.do
and that is clearly something user do not expect and do not want to. So
the better way from the point of convenience was to behave as pwd -L by
default.
Probably we can check both -L/-P behaviours during path resolution to
the target to check if the target is actually something known and
existing? Unfortunately no, we can not do that at all, according to:
https://unix.stackexchange.com/questions/79571/symbolic-link-recursion-what-makes-it-reset/79621#79621
With the path a/b/c, where a/b/c is a symlink to /somewhere, a/b/c/../d
may lead both to a/b/d, or to /somewhere/d, that are completely
different paths, but pretty valid from the point of symlinked paths. And
both a/b/d and /somewhere/d can be existing files. So there just can not
be any "valid" way of behaving when dealing with symlinks. That is one
of the reason Plan9 completely criticise and abandoned that idea:
http://harmful.cat-v.org/software/symlinks
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-04-22 9:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-16 19:13 Support for virtual targets Jan Niklas Böhm
2022-04-16 21:11 ` Sergey Matveev
2022-04-17 20:37 ` Resolving paths within symlinked dirs (Re: Support for virtual targets) Jan Niklas Böhm
2022-04-22 9:27 ` Sergey Matveev [this message]
2022-04-22 20:42 ` Resolving paths within symlinked dirs targets Jan Niklas Böhm
2022-04-24 18:34 ` Sergey Matveev