how to get around rsync error (OS X Tiger)

Lee Cullens lee_cullens at
Tue Aug 23 05:19:29 GMT 2005

Lee Cullens wrote:

> Lee Cullens wrote:
>> Wayne Davison wrote:
>>> On Mon, Aug 22, 2005 at 09:57:13AM -0400, Lee Cullens wrote:
>>>> 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?
>>> Yes, all separate filenames will be separate files without -H.
>>> ..wayne..
>> Thanks for all your help and patience Wayne.
>> Lee C
> FYI Wayne,
> In differentially updating a full clone with rsync, I don't want to be 
> creating duplicate files in something that is intended for restoring a 
> working volume, so I included the -H option.  Unfortunately that bring 
> me back to the conflict in OS X :-(
> The specific error message encountered with --inplace already included 
> an tested an adding just -H for testing:
> rsync: open "/Volumes/LaCie_Disk_B/System/Library/CoreServices/BootX" 
> failed: Operation not permitted (1)
> Maybe I can come up with some fun and games to salvage the effort.
> Lee C
Progress (maybe)

Rather than try to remove the BootX file temporarily I went back to my 
excludes list and added /System/Library/CoreServices/BootX - not the 
previous more general /System/Library/CoreServices/ trial.

That took care of the latest problem and I believe in limiting the 
exclude to just the BootX file I will not introduce any system 
inconsistencies.  Such is based on my reading everything I could find on 
OS X BootX - specifically its role in the boot process. I can't see 
where it would change within a system update (e.g. 10.4.2) version, and 
probably not even within an upgrade version (e.g. 10.4).  Upgrades and 
updates trigger a full asr clone immediately before and after to 
separate volumes, and the rsync differential updating of a clone would 
not span such a system change. 

If anyone thinks I might not have grasped the dynamics of the BootX file 
please speak up.

I have subsequently noted another issue with rsync that I think needs 
cleared up though.  If on my source volume I have a file on my desktop 
and I trash such, then boot to a third volume to perform the rsync 
differential update of the source clone I get the following error.

rsync: delete_one: unlink 
"/Volumes/LaCie_Disk_B/Users/Chinook/Desktop/._diffclone" failed: No 
such file or directory (2)

In this case "diffclone" was the file I trashed on the source volume and 
it gets deleted on the source clone.  I assume "._diffclone" was the 
associated metadata on the source and was not present on the clone.  So 
why should I get an error from rsync?

If I don't settle these questions before "publishing" the scripts, I'm 
sure to get a load of questions after :-)

Thank you,
Lee C

More information about the rsync mailing list