Re: file access time and file modification time

On Tue, 9 Jul 2019 10:48:32 -0400
Chet Ramey <chet.ramey@case.edu> wrote:

> On 7/9/19 6:16 AM, kfm@plushkava.net wrote:
> 
> >> Did you have a look at the 'conditional.sh' script too? Looks like the 
> >> '-N' switch compares only the integer part of the timestamp seconds.
> > 
> > The stat structure supports timestamp fields of nanosecond granularity 
> > since POSIX.1-2008, so it should work. I tried a simple test case here, and 
> > the behaviour of -N seems generally broken:
> > 
> > # f=$(mktemp); [[ -N $f ]]; echo $?; touch -m "$f"; [[ -N $f ]]; echo $?
> > 0
> > 0
> > 
> > I expected the value of $? to be non-zero at first, followed by 0 after 
> > updating the mtime. 
> 
> 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.

> 
> Using the test command that ships with GNU coreutils (v8.31) exhibits the
> same problem:
> > 
> > # f=$(mktemp); command test -N "$f"; echo $?; touch -m "$f"; command test 
> > -N "$f"; echo $?
> > 0
> > 0
> 
> It might, but that's not what you tested. This runs the builtin test.

Ah, how silly of me. I had also tried with the fully qualified path of test 
before posting, at least.

-- 
Kerin Millar <kfm@plushkava.net>