public inbox for goredo-devel@lists.stargrave.org
Atom feed
From: Sergey Matveev <stargrave@stargrave•org>
To: goredo-devel@lists.cypherpunks.su
Subject: Re: goredo gets confused with relative paths and symlinks
Date: Fri, 24 Oct 2025 15:12:58 +0300 [thread overview]
Message-ID: <aPttSuJF93Bm5-bP@stargrave.org> (raw)
In-Reply-To: <CAJoaZ9JF5ZdkAfo+NfWEeBeWx_XHPLybqrZJzPhFxsUg=cSa9w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1073 bytes --]
*** Rafael Fourquet [2025-10-23 16:58]:
>1) the "bug" I reported happens even when there is no symlink within
>the "redo project" itself.
Questions and problems with symlinks were raised a while ago in that
maillist and I remember that basically they are not solvable in general
case. spacefrogg's advice not to use symlinks is best we can do.
>IOW, I think it's definitely a bug for goredo to interpret the failure
>of ` unix.Access(doFile.rel, unix.X_OK)` to mean that the file isn't
>executable, when in fact it just means that the file is non-existent
As I can see, Access() will be called only if do-file is found. It
should return earlier if it was not. Or maybe symlinks completely breaks
absolute/relative paths resolution and indeed it deals with different
views to the same file?
http://harmful.cat-v.org/software/symlinks
https://unix.stackexchange.com/questions/79571/symbolic-link-recursion-what-makes-it-reset/79621#79621
--
Sergey Matveev (http://www.stargrave.org/)
LibrePGP: 12AD 3268 9C66 0D42 6967 FD75 CB82 0563 2107 AD8A
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]
next prev parent reply other threads:[~2025-10-24 12:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-23 13:54 goredo gets confused with relative paths and symlinks Rafael Fourquet
2025-10-23 14:10 ` goredo
2025-10-23 14:58 ` Rafael Fourquet
2025-10-24 12:12 ` Sergey Matveev [this message]
2025-10-24 13:45 ` Rafael Fourquet
2025-10-24 13:59 ` Sergey Matveev
2025-10-24 12:03 ` Sergey Matveev
2025-10-26 14:34 ` Sergey Matveev