OSX 10.6.4 error with -R option
henri.shustak at gmail.com
Thu Sep 2 17:04:51 MDT 2010
>> I have had reports of problems with the -R option on OSX 10.6.4.
>> Just tested it myself and found this odd result:
>> When I run this
>> "dtruss -f path/to/rsync -aHAXNR --fileflags --force-change --protect-decmpfs --stats -v /Users/astrid/Documents/main.m /Users/astrid/Desktop/rrr
>> it produces the expected results with the relative folder paths in place
>> but copying file from Desktop itself
>> "dtruss -f path/to/rsync -aHAXNR --fileflags --force-change --protect-decmpfs --stats -v /Users/astrid/Desktop/main.m /Users/astrid/Desktop/rrr
> Problem solved
> Sorry. I didn't even think to check permissions on the Desktop folder, the first logical thing to check. Somehow they had been changed. Fixed them and -R works fine now. I believe other users are likely having permissions issues too.
I have made the same mistake myself and have had the issue reported to me on multiple occasions in the past. This is why LBackup now checks the permissions are enabled on the destination volume.
Perhaps when rsync runs on OS X systems it should default to a mode where a permissions are enabled check is performed on the destination volume and then a warning could be reported if they are not enabled? Just a possibility to avoid many more people having this same issue?
Quoted below is an example of the output from LBackup when the permissions on a destination drive is not enabled :
> WARNING! : Permissions are disabled on backup destination volume.
> It is recommended that permissions on the destination volume are enabled.
> Failure to enable permissions will most likely result in the hard link system failing.
> Permissions may be enabled by issuing the following command as root :
> /usr/sbin/vsdbutil -a "/Volumes/volume_name"
Perhaps adding something like this directly into rsync is a good idea for Mac OS X users?
This email is protected by LBackup, an open source backup solution.
More information about the rsync