@node FAQ
+@cindex FAQ
@unnumbered FAQ
@anchor{Stamping}
+@cindex hashing
+@cindex stamping
@section Hashing and stamping
-All targets are checksummed if target's @file{ctime} differs from the
-previous one, or @env{$REDO_INODE_NO_TRUST} environment variable is set.
-@command{apenwarr/redo} gives
+All targets are checksummed if target's size, @code{ctime}/@code{mtime}
+differs from the previous one (depending on @ref{OOD, @env{$REDO_INODE_TRUST}}
+value). @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
produce empty output files. @command{apenwarr/*}, @command{redo-c} and
- @command{goredo} implementations consider non existing file as an
+ @command{goredo} implementations treat non existing file as an
out-of-date target
@item If you really wish to produce an empty target file, just touch @file{$3}
@end itemize
-Those who create an empty file if no @file{stdout} was written -- failed
-implementation.
+Those who create an empty file if no @file{stdout} was written -- are
+failed implementations.
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
necessary results in @file{$3}, instead of just silently feeding them in
@command{redo-stamp}.
-redo implementations are already automatically record -ifchange on
+redo implementations already automatically record -ifchange on
@file{.do} files and -ifcreate on non-existing @file{.do} files. So why
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.
+Zen of Python is not applicable there, because -ifchange/-ifcreate
+contradicts 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
Skein/BLAKE[23] algorithms demonstrate us.
@command{goredo} includes @command{redo-stamp}, that really records the
-stamp in the @file{.rec} file, but it does not play any role later. It
+stamp in the @file{.dep} 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.rec}.
+then remove @file{foo/.redo/bar.dep}.
@section Does redo-always always rebuilds target?