how to get around rsync error (OS X Tiger)

[Lee Cullens]

Wayne Davison wrote:

>On Sun, Aug 21, 2005 at 09:31:10PM -0400, Lee Cullens wrote:
>  
>
>>So, the option to override this behavior would be "--inplace" I
>>assume, and do yo know of any caveats regarding such locally? 
>>    
>>
>
>If you're doing a local transfer, (which implies --whole-file), the only
>adverse effect of --inplace would be noticed if the destination files
>are in-use.  So, if the destinations are for backups, that's not a
>problem.  For transfers that are not using/implying --whole-file, using
>--inplace can make some updates as inefficient as if --whole-file had
>been used (i.e. if potentially matching data is overwritten before it
>can be used).
>
>  
>
>>If I might be so naive, may I also ask about the "-H" option?
>>    
>>
>
>Using -H tells rsync to look for files with identical inodes in the
>transfer and hard-link them together.  It doesn't notice if a file is
>supposed to be hard-linked to a file outside of the transfer (since it
>doesn't know anything about files outside of the transfer).
>
>..wayne..
>
>  
>
Thanks for the clairification Wayne,

As I previously noted, I'm addressing local transfers and using a third 
boot volume for the transfer.  So --inplace would only be an issue (an 
efficiency issue at that) if used (as it might need to be) with OS X for 
a remote transfer.  Being thorough and accurate are important to me in 
the comprehensive "Backup::Restore" article I'm working on. 

Your clairification of the -H option adds to my understanding, but I'm 
still not completely clear on the consequences.  As I'm sure you already 
know, in OS X symbolic links are critical,  and hard links are (to my 
knowledge)  pretty much involved with only the workings of invisable 
Unix files.  Their importance then is mainly in copying one OS X volume 
to another.  Where I am unclear is if in not using -H a hard link (i.e. 
a duplicate directory entry for a file) will result in duplicated files?

Thanks again,
Lee C