public inbox for goredo-devel@lists.cypherpunks.ru
Atom feed
From: Spacefrogg <spacefrogg@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 12:49:59 +0100 (GMT+01:00)	[thread overview]
Message-ID: <e8df6a33-afb7-4f6a-a84b-cdebefc7c782@spacefrogg.net> (raw)
In-Reply-To: <b75eb2a3-0fed-0e0a-cd8f-da7b4a50830a@jnboehm.com>

>     a: inode=646, mtime=1667292427
>     b: inode=646, mtime=1667292427

Your bug is right here. This is a misuse of redo and breaks its logic. A and B are expected to mean different things, so they MUST NOT point to the same inode. Period.

>     a: inode=655, mtime=1667292646
>     b: inode=655, mtime=1667292646  # wasn't redone, but changed

This is, where you trigger the bug. Yes, reverting goredo resolves this exact TRIGGER of the bug. Your actual bug is still present, see above.

I reiterate: Separate paths MUST represent separate inodes or you break redo logic one way or another.

Your bug has nothing to do with the change in 1.23. I don't see why your case of misusing redo should be given any preference over a completely useful optimisation that is in line with the logic of redo.

One way out of your mess is that you create a c.do with an indirect dependency:
redo-ifchange a
ln a b # indirect dependency
touch $3

Users have to depend on c and know that they should use b. Now, you are honest to your consumers, that b is some dirty optimisation that may/will be changed whenever a is changed.

Final words: I sympathize with what you are trying to achieve. But you should rather fix the bug instead of removing one of its triggers.

Kind regards,
–Michael

  reply	other threads:[~2022-11-01 12:16 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
2022-11-01  9:02       ` Jan Niklas Böhm
2022-11-01 11:49         ` Spacefrogg [this message]
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