Subject: Re: Suggestion to revert touching files when the hash matches (problem with hardlinks)

From: goredo <[email-masked]>
Date: Tue, 1 Nov 2022 09:21:33 +0100 (GMT+01:00)

> 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).