bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bash conditional expressions


From: Greg Wooledge
Subject: Re: bash conditional expressions
Date: Sun, 14 Nov 2021 22:20:42 -0500

On Sun, Nov 14, 2021 at 09:57:49PM -0500, Dale R. Worley wrote:
> One thing you have to worry about is how "touch" behaves, and whether
> *that* has changed between Fedora versions.  I've run a few test uses of
> "touch" (in Fedora 34) and examined the consequences with "stat", and
> it's not clear to me exactly how "touch" behaves.

It's easy enough to find out, if you only care about the behavior of
a single instance of it, on a Linux-based system.  Here's what Debian 11's
implementation (which is from GNU coreutils 8.32) does:

unicorn:~$ strace touch x
[...]
openat(AT_FDCWD, "x", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = 3
dup2(3, 0)                              = 0
close(3)                                = 0
utimensat(0, NULL, NULL, 0)             = 0
close(0)                                = 0
close(1)                                = 0
close(2)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

The man page for utimensat(2) tells me:

         If times is NULL, then both timestamps are set to the current time.

And:

       On  Linux,  futimens()  is a library function implemented on top of the
       utimensat() system call.  To support this, the Linux utimensat() system
       call  implements  a  nonstandard feature: if pathname is NULL, then the
       call modifies the timestamps of the file referred to by  the  file  de‐
       scriptor  dirfd (which may refer to any type of file).

So, it opens the file, does a file descriptor manipulation dance, and
then sets the file's mtime and atime to the current time.

The significance of "setting the atime" will depend on the mount options
of the file system in question.  On Debian 11, a file system of type ext4
which is mounted with "defaults" (as specified in fstab) includes the
"relatime" option.  Which is documented thus:

       relatime
              Update inode access times relative to  modify  or  change  time.
              Access time is only updated if the previous access time was ear‐
              lier than the  current  modify  or  change  time.   (Similar  to
              noatime,  but  it  doesn't break mutt or other applications that
              need to know if a file has been read since the last time it  was
              modified.)

              Since Linux 2.6.30, the kernel defaults to the behavior provided
              by  this  option  (unless  noatime  was  specified),   and   the
              strictatime  option is required to obtain traditional semantics.
              In addition, since Linux 2.6.30, the file's last access time  is
              always updated if it is more than 1 day old.

I'm far too tired to parse that.  Just know that this stuff exists,
and it affects things.  Anything that tries to use atime in any sort of
serious capacity is going to have to worry about these options.

As I said earlier in this thread, atime is not a reliable thing on modern
systems.  It's *expensive*.  That's why systems are more and more often not
doing it.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]