bug with rsync changing modification dates even with the -a option

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


Solution 1:

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:

 st_atime         Time when file data last accessed.  Changed by the mknod(2), utimes(2) and read(2) system calls.

 st_mtime         Time when file data last modified.  Changed by the mknod(2), utimes(2) and write(2) system calls.

 st_ctime         Time when file status was last changed (inode data modification).  Changed by the chmod(2), chown(2), link(2), mknod(2), rename(2),
                  unlink(2), utimes(2) and write(2) system calls.

 st_birthtime     Time of file creation. Only set once when the file is created. This field is only available in the 64 bit inode variants. On filesys-
                  tems where birthtime is not available, this field holds the ctime instead.

Tools such as cp,ditto, and pax 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.

rsync -avXN --delete SOURCE DESTINATION

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.