The mtime of a file is not copied fully when -a option is invoked. This can be seen only when --full-time is used to display the original and the copied files. In particular the last three digits of the copy mtime (the nano-seconds part) are always zero in the copy.
This plays nasty when one attempts to use the -u option in cp. The -u option seems compare all digits of mtime, and fails to reject an un-needed update. And the error is not self-healing, as the new, un-need copy also fails to bring the two mtimes into congruence. Most coreutils seem not to record fractional parts of a second in mtimes, but touch does, and I'm sure other utilities and programs do, also. I'd like to have a -u option that actually works to prevent copy of files in a backup file system when the backup is up-to-date. This could be fixed by having -u examine only time digits that cp actually copies, or by fixing -a to actually copy all digits. I don't much care which, as they are surely meaningless as to the actual time of the modification event. I just need consistency. (I discovered this when I looking at --backup='numbered' as a way to preserve earlier versions of files for historical study. Once a file is 'corrupted' with non-zero nanosecond digits, it is 'forever new' ;-) Questions to think about: 1/ Is recording mtime to nearest nanosecond required by some standard? 2/ Wouldn't recording to nearest microsecond be good enough? 3/ Does this effect happen also in tar -u, mv -u (across file systems0, etc. ? ... Data from my tests follow: 'hide' is the source directory and 'hide1' is the copy. [EMAIL PROTECTED]:~/Drop-box$ l --full-time hide* hide: total 124 -rw-r--r-- 1 pec pec 52091 2006-10-05 11:09:48.000000000 -0600 xtn.ps -rw-r--r-- 1 pec pec 1390 2006-10-05 11:18:43.000000000 -0600 xtn.txt -rw-r--r-- 1 pec pec 1503 2006-10-17 11:39:48.634185012 -0600 xtn.txt~ -rw-r--r-- 1 pec pec 55443 2006-10-05 11:27:46.000000000 -0600 xtn1999.ps hide1: total 124 -rw-r--r-- 1 pec pec 52091 2006-10-05 11:09:48.000000000 -0600 xtn.ps -rw-r--r-- 1 pec pec 1390 2006-10-05 11:18:43.000000000 -0600 xtn.txt -rw-r--r-- 1 pec pec 1503 2006-10-17 11:39:48.634185000 -0600 xtn.txt~ -rw-r--r-- 1 pec pec 55443 2006-10-05 11:27:46.000000000 -0600 xtn1999.ps To do this test, I touched xtn.txt~ just before doing; [EMAIL PROTECTED]:~/Drop-box$ cp -a hide hide1 -- Paul E Condon [EMAIL PROTECTED] _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
