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.
I had the same experience when using /tmp but using $TMPDIR worked as expected:
$ touch "${TMPDIR}/tmp.txt"
$ ls -l "${TMPDIR}/tmp.txt"
-rw-r--r-- 1 luomat staff 0 Dec 3 08:46 /var/folders/8k/0bqq33mn439938qxp7j7c1fc0000gn/T//tmp.txt
Best Answer
Are you copying to a mounted volume that is on another system? If so, it may be confusing the uid and gid's.
Or are you copying to a NAS which might have an override setting for the ownership of the connected user. For example FreeNAS has options for NFS mounts to Mapall User and Mapall Group, and for AFP mounts to set default file and directory permissions
you can check for uid with something like
dscl . -read /Users/ UniqueID
and check for group id with
cat /etc/groups
or
dscacheutil -q group
Could you try tar'ing up a few files, copying them to the new volume and then untar'ing them and then check the file permissions?