help-make
[Top][All Lists]
Advanced

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

Re: Time stamp resolution


From: Jason Pearce
Subject: Re: Time stamp resolution
Date: Mon, 24 Jan 2005 22:31:19 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910

I get your points about touch. My application is really using redirected output into a .fail file, then /bin/mv to move it to the target. The touch example just seems to be a simple replication of the behaviour I am seeing.

I just tried the .LOW_RESOLUTION_TIME tip from David, alas no joy there either.

Paul D. Smith wrote:

%% Jason Pearce <address@hidden> writes:

 jp> For example:
 jp> > touch file1; touch file2
 jp> Can I then rely on (time stamp of file1) < (time stamp of file2)?

It depends on your filesystem.  Many filesystems only record timestamps
with a resolution of one second.  Most modern computers are fast enough
to execute those two operations in less than a second.  In that case,
quite often the two files will have the same timestamp.

Newer filesystems can record timestamps at sub-second accuracy, then you
might get different numbers.

Finally, note that even though your filesystem can record sub-second
timestamps not all UNIX tools can _UTILIZE_ sub-second timestamps.  The
file formats for tar and cpio, for example, have no way to store a
timestamp other than normal per-second accuracy.  Most system calls,
including utime(2) which is what touch is typically using, don't have
any ability to set sub-second timestamps, so tools like touch and cp -p
might not be able to copy them.


And really finally, note that touch traditionally behaves differently
when the file being touched exists vs. when it doesn't exist, in some
important ways.  When the file exists, touch will set the mod time
(using utime(2) usually) to the current system clock.  When the file
doesn't exist, touch just creates the file but doesn't try to set the
timestamp.  This means it's left up to the filesystem to set it.

This difference matters in two ways: first, as already discussed, a
filesystem might set a sub-second timestamp while touch, using utime(2),
might only be able to set with second accuracy.

And second, if you have a networked filesystem then a touch of a
non-existent file uses the timestamp of the server (since the server's
filesystem creates the file) while a touch of an already-existing file
uses the timestamp of the client (since it's set directly with
utime(2)).  This can matter if the clocks of your client and server are
not synchronized precisely.






reply via email to

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