Issues installing rsync 3.0.9 - Mountain Lion

You probably installed your version of rsync to /usr/local/bin

Run "/usr/loca/bin/rsync --version" to see what you get.

correction: Run "/usr/local/bin/rsync --version" to see what you get.

You don't need to install all those patches, the most recent rsync has all the modern features for OSX. The reason it is not installed by default is a licensing conflict.

Once installed, it should be found at

/usr/local/bin/rsync

however the system path will still use the rsync at

/usr/bin/rsync

You CAN just delete the old rsync which forces OSX to use the newer rsync. But unfortunately every OSX update will replace the missing rsync and suddenly your script won't work. If you are running rsync in Terminal no problem, just set an alias pointing to the new rsync in .bash_profile. But is you are running rsync in a script, it will use the wrong version. In that case you will need to set the system path in file:

/private/etc/paths

In this file you move folder

/usr/local/bin

ahead of

/usr/bin

Reboot and it should be fixed persistently.

as a matter of curiosity, what would happen if I deleted the built-in rsync and replaced it with a symbolic link to the newer version? Would that be enough to keep future updates from replacing the missing default version?

No, Apple Updater will overwrite the symlink with the old program. Yes, it's maddening.

I even filed a bug report on it but Apple doesn't care because we should all be using Time Machine.

lol - well, I guess that's why the unix mavens always use full paths.

I think the version of rsync shipped with Mac OS X has a different extended attribute option specification. Any script or utility that was written for Mac OS X using rsync and wanted to preserve Mac OS X extended attributes would not function properly.

Replacing the shipped rsync with the open source rsync is not a wise idea.

Standard *NIX thinking is that /usr may be updated anytime the system is updated, and /usr/local belongs to the root user and won't be updated. Apple is only following *NIX standards, and has nothing to do with TimeMachine so this is not a bug.

I upgraded rsync a while ago with no issues. the trick is to leave the original rsync exactly where it is and put the upgraded version in /usr/local/bin/ (then make sure that /usr/local/bin is after /usr/bin in the $PATH variable). That way the system will continue to use the old version of rsync, and any new or updated scripts you make can be pointed to the new verion.

twtwtw, that is a smart way to do it.

Note: it is OK to change your personal PATH to have /usr/local/bin before /bin and /usr/bin, as long as it is not global for every account, especially not for the 'root' account, for the exact reasons you stated.

Just as an update to this discussion, I am seeing more rsync errors all the time as OSX works in more ACLs and other new stuff I don't really understand. Just ignoring the errors for now, I don't know where rsync is going with all this new stuff.

Just as an update to this discussion, I am seeing more rsync errors all the time as OSX works in more ACLs and other new stuff I don't really understand. Just ignoring the errors for now, I don't know where rsync is going with all this new stuff.

Are you using the --extended-attributes (-E) on the default Mac OS X version or if using the latest OpenSource version are you using the --xattrs (-X).

Also if using the latest OpenSource rsync, are you also specifying --acl (-A) (Mac OS X version includes ACLs as part of --extended-attributes), and --perms (-p which you most likely are, as it is a common option, often included as part of --archive (-a).

Another question is what is your destination file system? Is it another Mac OS X HFS+ file system, or are you going over the net to a network attached storage (NAS) device, or a Unix system (Linux, Solaris, AIX, HP-UX, etc...), or a Windows system, or other? The destination may have issues of its own preserving all Mac OS X file attributes.

Message was edited by: BobHarris

I am using -aAEXW so that should cover all the options you mentioned. The errors I see look like this:

rsync: unpack_smb_acl: sys_acl_get_info(): Undefined error: 0 (0)

and

ERROR: Library/Mobile Documents.11520494/com~apple~mail/Data/MailData/Signatures/ubiquitous_846A634C- 6CBF-4749-BF46-4CD295955C80.mailsignature failed verification -- update discarded.

and

Library/Mobile Documents.11520494/com~apple~mail/Data/MailData/Signatures/ubiquitous_846A634C- 6CBF-4749-BF46-4CD295955C80.mailsignature

971 100% 0.00kB/s 0:00:00 (xfer#612, to-check=1969/136533)

rsync: read errors mapping "~/Library/Mobile Documents.11520494/com~apple~mail/Data/MailData/Signatures/ubiquitous_846A634C- 6CBF-4749-BF46-4CD295955C80.mailsignature": Bad file descriptor (9)

WARNING: Library/Mobile Documents.11520494/com~apple~mail/Data/MailData/Signatures/ubiquitous_89C65664- 92C4-4278-90D0-C2EB24D2A083.mailsignature failed verification -- update discarded (will try again).

I'm not too worried about these errors, the important files are getting backed up.

Computer to server syncing works fine.

brew install https://raw.github.com/Homebrew/homebrew-dupes/master/rsync.rb

best guess: these erors relate to storing one or two of your mail signatures related to specific emails to iCloud. That could mean that the emails are corrupt, or missing, or contain data that rsync doesn't know how to handle, or... You can figure out which signature(s) they are by following the path and opening the file in a text editor, but I why? Rebuild your mailboxes, or just just exclude that entire folder from your backups.