cp -u copies old files that already exist in the destination directory
 

Hi,

I am using CentOS 5.8 x86_64. I have 2 hard disks, one containing the / paritition and all user files, and a 2nd one
which I use as a backup disk. I normally do a backup by using "cp -a -u" so only new files created since the last
backup need to be copied to the backup disk. I have been doing this for a number of years without any problems.
Recently, however, I noticed that the "cp -a -u" commands keeps trying to copy certain old files that already exist
on the backup disk (my cp command is aliased to "cp -i", so I get prompted whenever it tries to overwrite an existing
file). It only does this for a small number of old files, but it keeps doing it to the same old files every time I
execute "cp -a -u". I checked the time stamps of the files both on my home directory and the backup disk and they are
exactly the same (as they should be). I even tried to do a' touch' on the old files on the backup disk, so they end
up having a newer time stamp than the files on the home directory - to no avail: "cp -a -u" still tries to copy them.

Does anyone have an explanation for this strange behaviour, and how to fix it?

Thanks in advance,
Terence

Why cp? Why not rsync? It's better for this sort of thing.

Are you copying to any type of FAT filesystem? Those can only represent time to a resolution of 2 seconds, so any source file with an odd-number timestamp will appear to be 1 second newer than the destination. With rsync there is a "--modify-window=" option to mask that.

Thanks for your replies.

sag47: After posting my original question I discovered rsync and it works well, so in future I'll probably
use that. But this still doesn't explain the weird behaviour of 'cp -u', which as I said, only appeared
recently/ The only recent change to my set up is that I bought a new PC and re-organized my partitions
differently, but this should not have caused 'cp -u' to behave differently.

rknichols: No, I don't have any FAT filesystems, only ext2/3/4. Even if the time stamp resolution problem
also happens in ext2 filesystems, this still wouldn't explain why after doing a 'touch' on the destination
file several weeks after the original was created, the problem still recurs.