Re: [PATCH] cp --update --preserve

[Paul Eggert]

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.