@node OOD
+@cindex OOD
+@cindex checksum
@unnumbered Out-of-date determination
The main task for build system is deciding if the target is out-of-date
uses @url{https://github.com/BLAKE3-team/BLAKE3, BLAKE3} with 256-bit
output for that purpose.
-Also it stores file's size. Obviously if size differs, then file's
-content too and there is no need to read and hash it.
+Also it stores file's size and its inode number. Obviously if size
+differs, then file's content too and there is no need to read and hash it.
+@vindex REDO_INODE_TRUST
But still it could be relatively expensive. So there are additional
possible checks that can skip need of hash checking, based on some trust
to the underlying filesystem and operating system behaviour, controlled
Do not trust filesystem at all, except for file's size knowledge.
Most reliable mode.
+@cindex time
@item $REDO_INODE_TRUST=ctime
Trust @code{ctime} value of file's inode. It should change every time
inode is updated. If nothing is touched and @code{ctime} is the same,
@end table
+@cindex mtime
Pay attention that although @code{mtime} is considered harmful (link
above), and is hardly acceptable in build system like Make, because it
compares timestamps of two files, redo is satisfied only with the fact
granularity of 10ms.
@command{goredo} uses @env{$REDO_INODE_TRUST=ctime} by default.
+
+If you move your worktree to different place, then all @code{ctime}s
+(probably @code{mtime}s if you are inaccurate) will be also changed. OOD
+check will be much slower after that, because it has to fallback to
+content/hash checking all the time. You can use @command{redo-depfix}
+utility to rebuild dependency files.