Bug with crtimes and hard links?

[Chris Roehrig]

I've been getting spurious unnecessary copying of files on OSX when  
using the crtimes patch and the --crtimes -H options (version 3.0.4).

I can reliably demonstrate it (on OSX 10.5) by doing this several  
times (as root):
rsync -v -N -axHAX --delete-during --fileflags --force-change  /usr/ 
bin/    /tmp/foo/


I think I've tracked it down to the hard-link processing code in  
recv_file_entry() in flist.c around line 751:

Essentially, all hard links but the first will get their modtime set  
correctly (from first->modtime), but their crtime is inherited  
(incorrectly) from the previous invocation of recv_file_entry.

The obvious idea would be to add a crtime field to file_struct but  
that looks like it has some large potential impact and
I'm afraid I don't know the rsync codebase sufficiently to want to  
attempt a fix.


-- Chris