Mini-HOWTO: Fixing rsync on Tiger (Mac OS X 10.4.x)

[David Powell]

It is just the "performance" issue.  However, this issue is unacceptable 
because of the number of files I am synching.. millions.. sending all of 
these resource forks is just asking for trouble...  using RsyncX I only 
transfer a few thousand files each session but this error just transfers 
resource forks 24 hours a day.. and this is insane.

I would gladly keep using RsyncX except it has a tendency to get "Stuck 
on Stupid" and worry over a missing file or some such nonsence rather 
than moving on.

I have found another project to fix rsync, but it still suffers from the 
same problem but he/they have implemented some novel solutions to the 
problem.  Still the binary at onthenet is easy to install and seems to 
work pretty well.

http://www.onthenet.com.au/~q/rsync/

Q. wrote to me..

> I know in your notes you say this should only occur when the last  
> change time was more recent than the file's modification date, but  
> the net effect is that every resource copies every sync.
>
> Is this what you are talking about when you are referencing  
> getattrlist?  This seems more like spotlight data.. but perhaps I  am 
> wrong.

Unfortunately yes. When you use the unix stat() function call it will  
return an access time, a change time and a modification time. When  you 
modify the extended attributes of a file it will changes the  "change 
time" without touching the "modification time". Unfortunately  the unix 
function call for setting these times doesn't allow you to  set the 
"change time", and will instead set it to the current time,  hence the 
problem.

It appears that setattrlist() will allow the setting of a files  change 
time on a HFS+ volume which would eliminate this issue,  however it's 
syntax is somewhat complex, and I have not yet had a  chance to work out 
how to use it as my powerbook is currently in for  repairs.  So it might 
be a little while before I have this problem  fixed.

-------

Appearantly the RsyncX people uses Apple specific Carbon library calls 
to read and write data to accomplish not copying the resources.. 

David


J.D. Bakker wrote:

> At 09:54 -0500 01-12-2005, David Powell wrote:
>
>> ... ._resource forks being synced over and over despite the target 
>> file itself not moving..
>
>
> Is this Problem #4 mentioned in http://www.lartmaker.nl/rsync/ , or 
> something else ?
>
>> Missing fact...
>>
>> I am attempting a link-destination based multiple backup that creates 
>> hard links to files that are duplicates and only moves the changed 
>> files..  This implementation of rsync is not noticing the existing 
>> resource fork associated with the previous copy of the file so it 
>> moves the resource fork again.
>>
>> I hope this makes sense.
>
>
> It would help to know if you're doing a local copy or a networked one. 
> Could you show us the full rsync command used ?
>
> Are you experiencing data loss, or is this simply a performance issue ?
>
> Regards,
>
> JDB.