site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On 17 Dec 2004, at 13:18, Ben Bond-Lamberty wrote: drwxr-xr-x 20 useradmin AD\group 680 9 Dec 14:51 Users drwxr-xr-x 56 webadmin extension 1904 10 Dec 08:56 Web rsync -a /Volumes/Data /Volumes/backup1/test the Data drive's root becomes: drwxr-xr-x 20 useradmin AD\group 680 9 Dec 14:51 Users drwxr-xr-x 56 labadmin AD\group 1904 10 Dec 08:56 Web I applied the following patch to rsync.c: diff -u -r1.1.1.6 rsync.c --- rsync.c 3 Jan 2004 11:22:00 -0000 1.1.1.6 +++ rsync.c 21 Dec 2004 12:04:56 -0000 @@ -260,7 +260,7 @@ change to groups that the user is a member of */ change_gid = is_in_group(file->gid); } - if (change_uid || change_gid) { + if (!S_ISLNK(st->st_mode) && (change_uid || change_gid)) { if (do_lchown(fname, change_uid?file->uid:st->st_uid, change_gid?file->gid:st->st_gid) != 0) { _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... When (and only when) I issue the following command (as root), backing up Data to an attached Firewire drive The only thing I've been able to figure out is that there is a symlink in the User directory tree above that points to the Web folder. If I remove this symlink, the behavior vanishes--rsync doesn't touch the user/group of Web anymore. I have noticed this behaviour too. In my case, I'm using rsyncX (aka rsync_hfs v2.6.0 from the rsyncX CVS). It was causing trouble for me since it was changing a setgid program (slocate) to have the wrong group. Which prevents the attempt to change permissions if the target is a symlink. Darwin follows symlinks with chown, so the permissions on the pointed-to file/dir get changed otherwise. This email sent to site_archiver@lists.apple.com