coreutils
[Top][All Lists]
Advanced

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

Re: Why two `touch`es running back-to-back generate files with the same


From: Bob Proulx
Subject: Re: Why two `touch`es running back-to-back generate files with the same time?
Date: Fri, 10 Apr 2015 11:51:11 -0600
User-agent: Mutt/1.5.23 (2014-03-12)

Eric Blake wrote:
> Peng Yu wrote:
> > Hi, See below for the output. I have Mac OS X 10.9.5.
> > 
> > /tmp$ touch a; touch b
> 
> In many distributions, /tmp is mounted as a different type of
> filesystem, such as tempfs, and backed solely by memory not disk.  As
> part of that implementation, the designers did not think it was
> important to have fine-grained timestamps for that filesystem.

Things keep changing.  The typical /tmp tmpfs these days fully
supports nanosecond resolutions.

  $ df -T /tmp
  Filesystem     Type  1K-blocks  Used Available Use% Mounted on
  tmpfs          tmpfs   8388608 96576   8292032   2% /tmp

  $ stat /tmp
    File: ‘/tmp’
    Size: 520             Blocks: 0          IO Block: 4096   directory
  Device: 16h/22d Inode: 9121        Links: 12
  Access: (1777/drwxrwxrwt)  Uid: (    0/    root)   Gid: (    0/
  root)
  Access: 2015-04-10 11:01:02.114176141 -0600
  Modify: 2015-04-10 11:40:27.362166089 -0600
  Change: 2015-04-10 11:40:27.362166089 -0600
   Birth: -

> > Access: 2015-04-09 16:47:03.000000000 -0500
> > Modify: 2015-04-09 16:47:03.000000000 -0500
> > Change: 2015-04-09 16:47:03.000000000 -0500
> >  Birth: 2015-04-09 16:47:03.000000000 -0500
> 
> Just looking at the timestamps, it is fairly obvious that the filesystem
> you are testing on has only 1-second resolution (no sub-second
> resolution), so any series of actions that all complete within the same
> one-second window will create timestamps that round to that same second.
>  (It's worse on FAT filesystems, which have a 2-second resolution).

Even with nanosecond resolution on the file system running file
commands one after the other will produce timestamps within the
granularity.

  /tmp$ for x in $(seq 1 10); do touch t-$x; done
  /tmp$ ls -ldog --full-time t-*
  -rw-rw-r-- 1 0 2015-04-10 11:46:57.424876732 -0600 t-1
  -rw-rw-r-- 1 0 2015-04-10 11:46:57.436876819 -0600 t-10
  -rw-rw-r-- 1 0 2015-04-10 11:46:57.424876732 -0600 t-2
  -rw-rw-r-- 1 0 2015-04-10 11:46:57.428876761 -0600 t-3
  -rw-rw-r-- 1 0 2015-04-10 11:46:57.428876761 -0600 t-4
  -rw-rw-r-- 1 0 2015-04-10 11:46:57.428876761 -0600 t-5
  -rw-rw-r-- 1 0 2015-04-10 11:46:57.432876790 -0600 t-6
  -rw-rw-r-- 1 0 2015-04-10 11:46:57.432876790 -0600 t-7
  -rw-rw-r-- 1 0 2015-04-10 11:46:57.432876790 -0600 t-8
  -rw-rw-r-- 1 0 2015-04-10 11:46:57.432876790 -0600 t-9

Applications that care about timestamps such as make or anyone writing
a script using foo -nt bar must be able to handle this issue.  It has
been around forever.  And even with high resolution timestamps the
problem does not go away.

Bob




reply via email to

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