Paolo Montrasio <[EMAIL PROTECTED]> 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. _______________________________________________ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
