public inbox for goredo-devel@lists.cypherpunks.ru
Atom feed
From: goredo <spacefrogg-goredo@spacefrogg•net>
To: "Jan Niklas Böhm" <mail@jnboehm•com>
Cc: goredo-devel@lists.cypherpunks.ru
Subject: Re: Suggestion to revert touching files when the hash matches (problem with hardlinks)
Date: Tue, 1 Nov 2022 09:21:33 +0100 (GMT+01:00) [thread overview]
Message-ID: <ada8337f-2839-4907-bce7-07b73f673392@spacefrogg.net> (raw)
In-Reply-To: <64d10f4c-b1db-c04e-e238-ee7c26fd5595@jnboehm.com>
> The reason is that when both "a" and "b" point to the same inode and we have to redo both it roughly goes like this:
>
> echo aaa > a.tmp
> # goredo does the following, but only if a.tmp != a
> mv a.tmp a
>
This is not what happens, because your proposition was that b is constructed from a via ln. So, a and b point to the same inode. In the second run, redo links a to $3. Now, a, b and $3 point to the same inode, regardless of whether redo mv's $3 to a afterwards or not. This is where the toolchain breaks, because it looks like a changed underneath, because all three point to the same inode.
When you are stuck with hardlinks, that is unfortunate. Hardlinks don't work, by design. Reverting won't change that. It will only revert to a different error.
On the same note, softlinks to directories also don't work because of the distributed redo database. Redo relies on the property that there is one canonical path to its dependencies and it gets confused by softlinks opening up a second path.
All this said, the 2 basic rules to a working redo toolchain is: Things that mean the same entity must be referenced by the same path. And things that mean different entities must be referenced by different paths. (Links can violate either rule).
next prev parent reply other threads:[~2022-11-01 8:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-31 21:37 Suggestion to revert touching files when the hash matches (problem with hardlinks) Jan Niklas Böhm
2022-11-01 6:42 ` goredo
2022-11-01 7:50 ` Jan Niklas Böhm
2022-11-01 8:21 ` goredo [this message]
2022-11-01 9:02 ` Jan Niklas Böhm
2022-11-01 11:49 ` Spacefrogg
2022-11-01 13:14 ` Jan Niklas Böhm
2022-11-02 13:57 ` Sergey Matveev
2022-11-02 22:42 ` Jan Niklas Böhm
2022-11-03 8:55 ` Sergey Matveev