*** 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
