Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #15101
| From | Chet Ramey <chet.ramey@case.edu> |
|---|---|
| Newsgroups | gnu.bash.bug |
| Subject | Re: file access time and file modification time |
| Date | 2019-07-09 14:11 -0400 |
| Message-ID | <mailman.697.1562695966.2688.bug-bash@gnu.org> (permalink) |
| References | (1 earlier) <c7525b0b-937c-48e3-92f6-c5e5734b0426@email.android.com> <20190709111616.26148014b42ea4210f634e1e@plushkava.net> <80df53ac-2861-73e4-d1cb-86bf265b5550@case.edu> <20190709171204.d1cc42a73ef2f1148556a0d5@plushkava.net> <4c704f20-7d66-5bee-d937-d888877ce7ba@case.edu> |
On 7/9/19 12:12 PM, kfm@plushkava.net wrote: >> The code just returns (atime <= mtime), and has since 1997. It uses the >> st_atime and st_mtime fields. I should update it to use timespecs if >> they're available, and (mtime > atime) might work closer to your >> expectations. >> >> After the call to mktemp, the atime and mtime are the same, so the test >> returns true. > > I see. Indeed, it is confusing to me because I would not consider a file whose atime and mtime are equal to have been "modified since it was last read", notwithstanding that the newborn file has not yet been read at all. I think that it would help for the documentation to address this nuance. > > As for the possibility of using the timespec fields, that would be terrific. That's already done. And we'll try the (mtime > atime) variant as well. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/
Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread
Re: file access time and file modification time Chet Ramey <chet.ramey@case.edu> - 2019-07-09 14:11 -0400
csiph-web