how to get around rsync error (OS X Tiger)

[Lee Cullens]

Lee Cullens wrote:

> Wayne Davison wrote:
>
>> On Sun, Aug 21, 2005 at 02:43:50PM -0400, Lee Cullens wrote:
>>  
>>
>>> The most logical place to ask this question is this rsync forum, but
>>> no one has yet even acknowledged the issue.
>>>   
>>
>>
>> I was hoping that a MacOS user would respond and help you out since this
>> issue appears to be specific to MacOS.
>>
>> As for why the rename is happening, that's how rsync updates all the
>> files (unless overridden via options) -- it creates a new version and
>> renames it over the old version.  The main reason for this is because of
>> how the rsync algorithm works, but it is also a very safe idiom in that
>> any process that has the file open (such as when a program is using the
>> binary as read-only swap) is not disrupted as it would be if new data
>> was simply written out to the old inode.
>>
>> I assume the root issue has to do with something non-Posix going on with
>> the files in that directory, but I don't know enough about MacOS to be
>> able to speculate about what that might be.
>>
>> ..wayne..
>>
>>  
>>
> Thank you for the reply Wayne,
>
> Yes, that makes sense and, of course, yet another reading of the man 
> pages gives that impression if one is properly attuned :-)    So,  the 
> option to override this behavior would be "--inplace" I assume, and do 
> yo know of any caveats regarding such locally?
> If I might be so naive,  may I also ask about the  "-H"  option?   OS 
> X  Darwin is BSD with Apple's own twists thrown in,  and uses a lot of 
> hard links, symbolic links and their own "aliases" to present the file 
> system to the GUI user.  I am creating first a full direct (no 
> intermediate image) clone with asr of my working volume 
> "Mirrored_HD_Set" to an external HD "LaCie_Disk_A" (or B or C ...) as 
> a bootable volume and I know from testing that just reversing source 
> and destination in asr restores a fully functional working volume.  In 
> the file system "LaCie_Disk_A" is a mount point in /Volumes/ but I 
> notice the mount point of "Mirrored_HD_Set" is actually a symbolic 
> link to (guess what) "Mirrored_HD_Set/" (wherever that is) just to 
> give you an idea of the hijinks.
> Now, I am using the rsync options "-axEuvv --delete 
> --exclude-from=..."  (so far)  to differentially update the clone.  On 
> initial readings of the rsync man pages I included the -H option, but 
> on subsequent readings I took it out.  Can you tell me if I might be 
> wrong in doing so?
>
> Thanks again for your reply - it was greatly appreciated,
> Lee C

Wayne,

Sorry for missing such an obvious (in hind sight) thought.  I removed 
/System/Library/CoreServices/ from my excludes file and included the 
rsync --inplace option and the issue is resolved :-)  The differentially 
updated clone is still bootable and seems ok. I might add that the issue 
is resolved locally at least, because using the --inplace option is 
probably not the best way for a remote transfer.  Maybe the rsync 
developers will think about the OS X peculiarities in the future and 
possibly find a solution :-)

Anyway, as a last consideration before the ultimate test of restoring to 
my working volume from the updated clone, I'm reviewing my choice of not 
using the -H option. On initial readings of the rsync man pages I 
included the -H option, but on subsequent readings I took it out.   Any 
thoughts? 

Thanks for your help,
Lee C