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


Groups > gnu.bash.bug > #15099 > unrolled thread

Re: file access time and file modification time

Started by"" <kfm@plushkava.net>
First post2019-07-09 17:12 +0100
Last post2019-07-09 17:12 +0100
Articles 1 — 1 participant

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: file access time and file modification time "" <kfm@plushkava.net> - 2019-07-09 17:12 +0100

#15099 — Re: file access time and file modification time

From"" <kfm@plushkava.net>
Date2019-07-09 17:12 +0100
SubjectRe: file access time and file modification time
Message-ID<mailman.661.1562688734.2688.bug-bash@gnu.org>
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>

[toc] | [standalone]


Back to top | Article view | gnu.bash.bug


csiph-web