Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #15101

Re: file access time and file modification time

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>

Show all headers | View raw


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


Thread

Re: file access time and file modification time Chet Ramey <chet.ramey@case.edu> - 2019-07-09 14:11 -0400

csiph-web