rsync 2.6.9 on OS X. files with xattrs don't retain mtime.

Wesley W. Terpstra terpstra at gkec.informatik.tu-darmstadt.de
Fri Nov 10 15:18:51 GMT 2006


On Nov 10, 2006, at 3:55 PM, Wesley W. Terpstra wrote:
> On Nov 10, 2006, at 11:30 AM, Matt Jenns wrote:
>> I'm really excited about the recent work on extended attributes. I've
>> compiled 2.6.9 with xattr support, and run a few tests. It seems that
>> if I have a file with an extended attribute ( a resource fork in this
>> case), and I run rsync -aX , the mtime is not preserved.
>>
>> Is this the expected behaviour?
>
> No. However, it works for me

Now I've reproduced it.
When one sets the ResourceFork extended attribute, that resets the  
mtime, but this is not true for other attributes. Very odd.
It makes me wonder whether on some systems updating any attribute  
could reset the mtime. If that's the case the mtime has to be set  
after the chmod!

> Looking over the code, it does write extended attributes after  
> setting the mtime, but I wouldn't have thought this would matter.  
> Indeed, on my computer, it doesn't.

I've tried changing this (putting the mtime code after the xattr, but  
before the acl):

In direct sync case it works:
> ottawa:~/rsync/cvs terpstra$ ./rsync -axX peanut peanut3
> ottawa:~/rsync/cvs terpstra$ stat peanut*
> 234881035 3247760 -rw-r--r-- 1 terpstra terpstra 0 12 "Nov 10  
> 16:09:57 2006" "Nov 10 15:57:55 2006" "Nov 10 15:57:55 2006" 4096  
> 16 0 peanut
> 234881035 3247942 -rw-r--r-- 1 terpstra terpstra 0 12 "Nov 10  
> 16:09:57 2006" "Nov 10 15:57:55 2006" "Nov 10 16:09:57 2006" 4096  
> 16 0 peanut3

For two step updates, it still fails:
> ottawa:~/rsync/cvs terpstra$ ./rsync -ax peanut peanut2
> ottawa:~/rsync/cvs terpstra$ stat peanut*
> 234881035 3247760 -rw-r--r-- 1 terpstra terpstra 0 12 "Nov 10  
> 16:09:21 2006" "Nov 10 15:57:55 2006" "Nov 10 15:57:55 2006" 4096  
> 16 0 peanut
> 234881035 3247937 -rw-r--r-- 1 terpstra terpstra 0 12 "Nov 10  
> 16:09:21 2006" "Nov 10 15:57:55 2006" "Nov 10 16:09:21 2006" 4096 8  
> 0 peanut2
> ottawa:~/rsync/cvs terpstra$ ./rsync -axX peanut peanut2
> ottawa:~/rsync/cvs terpstra$ stat peanut*
> 234881035 3247760 -rw-r--r-- 1 terpstra terpstra 0 12 "Nov 10  
> 16:09:29 2006" "Nov 10 15:57:55 2006" "Nov 10 15:57:55 2006" 4096  
> 16 0 peanut
> 234881035 3247937 -rw-r--r-- 1 terpstra terpstra 0 12 "Nov 10  
> 16:09:21 2006" "Nov 10 16:09:29 2006" "Nov 10 16:09:29 2006" 4096  
> 16 0 peanut2
> ottawa:~/rsync/cvs terpstra$ ./rsync -axX peanut peanut2
> ottawa:~/rsync/cvs terpstra$ stat peanut*
> 234881035 3247760 -rw-r--r-- 1 terpstra terpstra 0 12 "Nov 10  
> 16:09:57 2006" "Nov 10 15:57:55 2006" "Nov 10 15:57:55 2006" 4096  
> 16 0 peanut
> 234881035 3247941 -rw-r--r-- 1 terpstra terpstra 0 12 "Nov 10  
> 16:09:33 2006" "Nov 10 15:57:55 2006" "Nov 10 16:09:33 2006" 4096  
> 16 0 peanut2

That is, if you sync a file directly, it gets the mtime+fork right  
(case: peanut->peanut3).
However, if you sync a file that is identical in all respects except  
the resource fork (xattrs), then the mtime is wrong for the first  
run, but not the second (peanut->peanut2).

Let's see what Wayne has to say; maybe the reason the mtime only gets  
updated on the second run is some deep rsync magic.



More information about the rsync mailing list