I have been testing rsync and found a weird bug when copying files and folders from a partition to another:
If I do this:
rsync -avE --delete '/Volumes/disk1/origin/' '/Volumes/disk2/destination/'
It copies/syncronizes correctly.
The next time I use rsync for the same syncronization, some modification dates in files (not folders!) become incorrect (are changed to the current date and time), even though I have used the -a
in the rsync
command which should preserve it.
The most weird thing is that if I redo it, the dates that were wrong are correct now, which means rsync is changing the modification dates every second time it is run, and when it changes the dates, it is always to the same files, I don't see a pattern other than just affecting files and the same files.
What am I doing wrong and can this be fixed?
This is with OS X 10.9.5, using the terminal, rsync 2.6.9
Best Answer
Let me correct my comment: A 64bit timestamp consist of
access-modification-change-birthtime
.From
man 2 stat
the following system calls change the respective times.The time-related fields of struct stat are as follows:
Tools such as
cp
,ditto
, andpax
can preserve OS X metadata when they are called to copy files. These tools will not preserve birthtime if the modification time is newer than the original file's birthtime. Birthtime of the new file is set to the modification time of the original file.If you compile rsync with the patches fileflags, crtimes, hfs-compression then rsync can handle OS X metadata and preserve the original file's birthtime on the new file.
So, you would call rsync like this.
I suggest that you have a long read of the rsync manual and understand the options that I have suggested before you attempt to apply them.