On Sat, 2008-08-02 at 15:50 -0500, Neil Gunton wrote: > The point of my original message wasn't so much to get a > workaround, as to suggest a new option for rsync that would make this > kind of task easier.
Well, it looks like you really know what you want here. You're welcome to create and use a modified version of rsync with the option, but inclusion of the option in the main rsync is doubtful (Wayne, please feel free to correct any of this). Everyone who uses rsync extensively, myself included, could probably name a bunch of options that would make their life easier. Even if many of the options are relatively simple, including all of them in the main rsync would make it even harder to maintain than it is. Our focus in adding options is not to make individual use cases easy but to make large groups of use cases easier. Users with complex or uncommon needs are expected to meet rsync halfway, and I am always happy to help them do so via this list. > That above perl solution sounds very complex. Not really. You just have to build rsync with the usermap.diff patch: http://rsync.samba.org/ftp/rsync/patches/usermap.diff put the scripts in Wayne's email on your $PATH, and use the rsync command he wrote. You're expected to meet rsync halfway here. It provides a generic mechanism to specify a uid/gid mapping, and you wire up your data to that mechanism. > The whole point of rsync in the first place was to simplify > backing up - I mean, you could have done what rsync does using a bunch > of perl code, but someone decided to try to make it simpler. I don't think that's a fair comparison: it would be ridiculous for everyone who wants to make a backup to write his/her own rsync, but it's not hard to use either the usermap patch or the chroot-over-ssh approach from my other email. > I think the > old/new uid issue is very common, given the scenario of backing up your > system to something like a a local USB hard drive and then trying to > restore your config to a newly installed system. I don't think restoring to a system where the user/group names correspond to different ids is as common as you believe. If I restored configuration files owned by system users to a newly installed system, I might let the overwritten config files keep the same attributes (in case they changed in the new install) instead of trying to preserve attributes. Plus, Fedora seems to be trying to standardize the uids/gids of system users across installs: https://fedoraproject.org/wiki/PackageUserCreation Matt
signature.asc
Description: This is a digitally signed message part
-- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
