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
next prev parent 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