[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] cp --update --preserve
From: |
Paul Eggert |
Subject: |
Re: [PATCH] cp --update --preserve |
Date: |
15 Jan 2004 09:57:18 -0800 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 |
Paolo Montrasio <address@hidden> writes:
> Paul's suggestion can be modified in this way:
>
> 1) read the timestamp of the existing destination file (if it doesn't
> exist yet we don't have any problem and we can resume normal
> processing)
> 2) write the current time to destination file's atime
> 3) find out how many significative digits there are in atime
> 4) restore the original timestamp
> 5) perform the check according to the number of significative digits
Yes, that's pretty much what I thought I was suggesting.
All these steps need to be done only if the time stamps are slightly
out of sync. If the source's time stamp is S and the destination's is
T, then 'cp' needs to do the above steps only if (S - (S mod 2) <= T
&& T < S), where by "mod" here I mean real-number modulo. The "2" is
because some DOSish file systems have a time stamp resolution of only
2 seconds, and all other time stamp resolutions that I know of are
equal to 2 seconds divided by some integer.
Step (2) should use a time with an odd number of seconds and with
nanoseconds = 999999999; that way, you're guaranteed to find out the
correct resolution of any file system that I know about. It's simple
enough to take the current time, subtract 1 second, then OR in 1
second, then set the nanoseconds field to 999999999; this will give a
time in the recent past that has the properties we want.
Step (4) cannot always be done: the original time stamp may have
nanosecond resolution, but we can't restore it. This is why I was
proposing doing it to a little test file instead. However, on further
thought, you're right that the atime doesn't really matter all that
much, so it's OK to just use the destination file as a guinea pig
whose time stamp can be futzed with temporarily a bit.
The further optimization I mentioned, is that you don't have to do any
of this stuff if you've already computed the time stamp resolution for
the destination file system.
> The smaller the resolution, the higher the chances are that you get
> some 0 in the least significative digits of the timestamp. For
> instance, if you have full nanoseconds resolution, the program will
> believe in the 10% of cases that you have a resolution of 10
> nanoseconds.
Not if you use nanoseconds==999999999 as I suggested above. That
should handle all of the cases correctly.