On Wed, Jan 10, 2024 at 6:36 PM Olivier Certner wrote: > Both the examples above prompt some straight objections on the current > usefulness of "atime". First, unless you've disabled building the locate > database in cron (enabled by default, on a weekly basis), access times on > directories lose most of their usefulness. Second, if using an IDS, I'm > afraid it's just game over. And even if you think you are not, > '460.pkg-checksum' at least is readily there to much complicate, or even > prevent you from, getting package usage information this way (it is enabled > by default, and on a daily basis). > > The general point here is that a single access time is inherently fragile to > interferences by multiple applications for multiple reasons.
I am reading this interesting discussion and please verify my general understanding: 1. There is a request for change in core OS / FS mechanism of file access time (atime) because of problem with mailing application? 2. Linux change of approach to atime that keeps its value only around last 24h so we should also change it in FreeBSD? 3. "realtime" is the alternative solution to keep atime intact? Why change well known standardized and widely used mechanism that is here for decades? If there is a problem with an application why change core OS/FS with all possible negative consequences and not fix the application? Wouldn't that break POSIX / backward compatiblity? Thanks :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
