*** Pedro Lucas Porcellis [2022-02-01 11:00]:
>I think for most people out there, relying on mtime is just perfectly fine.
No. mtime depends on time and filesystem implementation specifics.
There are many systems where sysadmins like to do cron-ed ntpdate,
which leads to jumping clocks. There could be filesystem/kernel
issues like low mtime value granularity:
https://stackoverflow.com/questions/14392975/timestamp-accuracy-on-ext4-sub-millsecond
There are many other possible unexpected problems:
https://apenwarr.ca/log/20181113
>I believe that generally, this kind of "futorology development thinking"
>can lead to developing very messy and complex solutions, because "we
>might hit that edgecase in the future that only 0.5% of users have
>then".
People like me want reliability, predictability and some expected
behaviour from the software, to trust and rely on it. mtime usage
safety depends on quantity of pitfalls, implementation specifics
and OS configuration options. We can "fix" those problems to make
usable systems friendly with software relying solely on mtime.
Or we can just can make less expectation of underlying FS/OS and
write software (redo in current case) that does not depend on all
of that fragile metainformation. Instead of depending on some OS
specific mtime/ctime/whatever inode field, that *should* be
updated if file's content is changed (but we already know that is
not expected from mmap-ed changes and FUSE-based filesystems), we
can depend literally on content itself (on its cryptographic hash
not to waste space). Reliable, predictable, OS/FS-independent
solution. Personally I am completely ok to have slightly added
delay because of data transfer and hash computation, because if
we talk about practical development tasks, there there are no huge
amounts of data involved. Possibly slightly worse performance, but
perfect reliability and predictability I can rely on.
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Received on Tue Feb 01 2022 - 16:26:32 CET