bug-coreutils
[Top][All Lists]
Advanced

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

incorrect copy of modify time in cp


From: Paul E Condon
Subject: incorrect copy of modify time in cp
Date: Tue, 17 Oct 2006 12:30:26 -0600
User-agent: Mutt/1.5.9i

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.

address@hidden:~/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;  
address@hidden:~/Drop-box$ cp -a hide hide1


-- 
Paul E Condon           
address@hidden




reply via email to

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