On Tue, Feb 01, 2022 at 09:29:55PM +0900, Pontus Stenetorp wrote: > On Tue 01 Feb 2022, NRK wrote: > > On Mon, Jan 31, 2022 at 12:10:27AM +0200, Petros Pateros wrote: > > > However, it was pointed out to me that relying on mtime can give > > > wrong results, for example: (a) if the clock is set backwards or > > > in case of insufficient granularity in mtime then a file that gets > > > modified might have the same mtime (b) an mmap(2)-ed file can get > > > modified but its mtime might not get updated soon enough > > > > How likely is it for these situations to occur in practice? If these > > are practical problems, then it makes sense to solve them. Otherwise > > I think it's best not to waste resource solving theoretical > > problems. > > Speaking for myself, I certainly have experienced issues with > inaccurate timestamps on NFS for compute clusters where its use is > very common. Not saying this as a supporter of NFS and the likes, just > as evidence that it does occur in practice.
Yeah, but again, how common is that scenario on a regular, day-to-day development? I think for most people out there, relying on mtime is just perfectly fine. 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". In the end it's like NRK said, in the end it's just a waste of resources. With best regards, Pedro Lucas Porcellis
