Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: "" <kfm@plushkava.net>
Newsgroups: gnu.bash.bug
Subject: Re: file access time and file modification time
Date: Tue, 9 Jul 2019 17:12:04 +0100
Lines: 42
Approved: bug-bash@gnu.org
Message-ID: <mailman.661.1562688734.2688.bug-bash@gnu.org>
References: <20190708092807.02edd68a60130b89a7775425@plushkava.net> <c7525b0b-937c-48e3-92f6-c5e5734b0426@email.android.com> <20190709111616.26148014b42ea4210f634e1e@plushkava.net> <80df53ac-2861-73e4-d1cb-86bf265b5550@case.edu> <20190709171204.d1cc42a73ef2f1148556a0d5@plushkava.net>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: Mischa Baars <mjbaars1977.bug-bash@cyberfiber.eu>, bug-bash@gnu.org
To: chet.ramey@case.edu
Envelope-to: bug-bash@gnu.org
In-Reply-To: <80df53ac-2861-73e4-d1cb-86bf265b5550@case.edu>
Precedence: list
Xref: csiph.com gnu.bash.bug:15099

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>