@anchor{Stamping}
@section Hashing and stamping
-All targets are checksummed if their @file{ctime} differs from the
-previous one. @command{apenwarr/redo} gives many reasons why every time
-checksumming is bad, but in my opinion in practice all of them do not
-apply.
+All targets are checksummed if no @env{REDO_INODE_NO_TRUST} environment
+variable is set and target's @file{ctime} differs from the previous one.
+@command{apenwarr/redo} gives
+@url{https://redo.readthedocs.io/en/latest/FAQImpl/#why-not-always-use-checksum-based-dependencies-instead-of-timestamps, many reasons}
+why every time checksumming is bad, but in my opinion in practice all of
+them do not apply.
@itemize
@item Aggregate targets and willing to be out-of-date ones just must not
@end itemize
DJB's proposal with both @file{stdout} and @file{$3} gives that ability
-to control your desired behaviour. Those who does not capture
-@file{stdout} -- failed. Those who creates an empty file if no
+to control your desired behaviour. Those who do not capture
+@file{stdout} -- failed. Those who create an empty file if no
@file{stdout} was written -- failed.
redo is a tool to help people. Literally all targets can be safely
@code{redo-stamp < $3}-ed, reducing false positive out-of-dates. Of
course, with the correct @file{stdout}/@file{$3} working and placing
necessary results in @file{$3}, instead of just silently feeding them in
-redo-stamp.
+@command{redo-stamp}.
redo implementations are already automatically record -ifchange on
@file{.do} files and -ifcreate on non-existing @file{.do} files. So why
-they can not record redo-stamp the same way implicitly? No, Zen of
-Python does not applicable there, because -ifchange/-ifcreate contradict
-it already.
+they can not record @command{redo-stamp} the same way implicitly? No,
+Zen of Python does not applicable there, because -ifchange/-ifcreate
+contradict it already.
Modern cryptographic hash algorithms and CPUs are so fast, that even all
read and writes to or from hard drive arrays can be easily checksummed
-and transparently compressed, as ZFS with LZ4 and Skein/BLAKE[23]
-algorithms demonstrate us.
+and transparently compressed, as ZFS with LZ4/Zstandard and
+Skein/BLAKE[23] algorithms demonstrate us.
@command{goredo} includes @command{redo-stamp}, that really records the
-stamp in the @file{.dep} file, but it does not play any role later. It
+stamp in the @file{.rec} file, but it does not play any role later. It
is stayed just for compatibility.
@section Can removed .do lead to permanent errors of its non existence?
have no confidence in such behaviour. So it is user's decision how to
deal with it, probably it was just his inaccuracy mistake. If you really
want to get rid of that dependency knowledge for @file{foo/bar} target,
-then just remove @file{foo/.redo/bar.dep}.
+then just remove @file{foo/.redo/bar.rec}.
@section Does redo-always always rebuilds target?
@command{goredo}, together with @command{apenwarr/redo}, rebuilds target
once per @strong{run}.
-Always rebuilds during every redo invocation, but only once during it
-building.
@url{http://news.dieweltistgarnichtso.net/bin/redo-sh.html#why-built-twice, redo-sh}
has other opinion, that is why its @file{redo-sh.tests/always_rebuild_1}
will fail. Rebuilding of always-ed targets even during the same build