[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