[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: file access time and file modification time
From: |
Mischa Baars |
Subject: |
Re: file access time and file modification time |
Date: |
Tue, 24 Sep 2019 08:48:30 +0200 |
User-agent: |
Evolution 3.32.4 (3.32.4-1.fc30) |
Hi Kerin and Chet,
Testing mailing list. My earlier replies didn't come through.
Regards,
Mischa.
On Tue, 2019-07-09 at 11:16 +0100, kfm@plushkava.net wrote:
> Hi Mischa,
>
> On Tue, 09 Jul 2019 09:05:45 +0200
> Mischa Baars <mjbaars1977.bug-bash@cyberfiber.eu> wrote:
>
> > Hi Kerin,
> >
> > That indeed solves the problem in 'accesstime.sh', although I would
> > recommend some sort of reference from the bash manpage to the mount
> > manpage.
> >
> > 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. 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
>
> That was with ext4 as the filesystem backing the TMPDIR. I also
> tested FreeBSD/UFS, with the same results, even if sleeping one
> second before updating the mtime. Perhaps Chet would be so kind as to
> clarify what's going on here. In the meantime, your technique of
> comparing the timestamps lexicographically seems like a good
> workaround, although you should use [[ instead. For example:
>
> # check() { local at=$(stat -c %x "$1") mt=$(stat -c %y "$1"); [[ $mt
> > $at ]]; }
> # f=$(mktemp); check "$f"; echo $?; touch -m "$f"; check "$f"; echo
> $?
> 1
> 0
>
- Re: file access time and file modification time,
Mischa Baars <=