Re: permissions bug w/ --backup-dir or --backup option?
Carey,
What you are seeing is, in fact, the case, but the function that creates
the dirs is robust_move() in backup.c
The backup option captures files and/or directories that are deleted or
changed between syncs. So, if a directory is *changed*
(deleted/renamed/moved), then the directory *and* it's permissions are
copied over. If a file (node, etc.) is changed, then the file and it's
permissions are carried over. If a directory is created by rsync simply
to position a changed file, then no permissions are carried over to that
directory (they are explicitly created 0755 by robust_move()).
This works great for us, because 1) it's faster, and 2) we really don't
care about the directory permissions/owners unless the directory is
changed directly by a move/rename/delete. That said, you do have a
point. (And, just because I don't use it, doesn't mean it's not right
:^)
Add one line to backup.c to do your thing. There will be a little
overhead, but it will work they way you want it to work, and smack
permissions on all directories on the backup-dir path leading to the
changed file(s).
** This patch works with both 2.4.6 and 2.4.7pre1 -- jmd **
** Don't forget to convert CR/LF (Dos Format) to LF (Unix Format) **
** before patching. Edit to remove line wraps, as well. **
-- Cut here
*** backup.c.orig Sat Aug 19 08:10:39 2000
--- backup.cThu Sep 20 08:17:19 2001
***
*** 266,271
--- 266,272
/* move to keep tree if a file */
if(!kept) {
+ make_bak_dir(fname,backup_dir); /* Set up permissions for path - jmd
*/
if (!robust_move (fname, keep_name))
rprintf(FERROR, keep_backup failed %s - %s : %s\n,
fname, keep_name, strerror(errno));
-- Cut here
Good suggestion, Carey!
Jim Delahanty
[EMAIL PROTECTED]
Carey Jung wrote:
James,
I think the problem with --backup-dir lies in make_bak_dir in backup.c.
From what I can tell by looking at the code, as it builds the backup
directory path, it's not setting mod times, ownership, and permissions on
the backed up directories, just on the backed up file. Make sense?
Carey
RE: permissions bug w/ --backup-dir or --backup option?
And we've done 19,658 runs so far (8/server/day), over 380 Gigs sync'd with an average of 44Meg(11Meg compressed) of data per run, and all of our backup files come across with correct owners and permissions. Whew! I'd look to your filesystem first. Do the rsync'd files (not backup-dir files) come across with the right permissions? Yes, the backed up file permissions are correct. The files that get moved to the backup-dir are not, though. Looking at it a littler closer, though, I think it's just the directory permissions/ownership that are getting lost. Permissions/ownership of individual files are preserved properly. Here's some further data: Command line (running as root): rsync -avz --timeout=0 --partial --force --ignore-errors --bwlimit=0 --stats -- \ numeric-ids --delete --backup --backup-dir=/archive/current/previous/server Sample permissions in backup directory: cd /archive/backups/current/server ls -ld home/company drwxrws--- 24 508 company 4096 Sep 18 12:04 home/company Sample permissions in backup-dir directory: cd /archive/backups/previous/server ls -ld home/company drwxr-xr-x 6 root root4096 Sep 18 12:04 home/company Carey
RE: permissions bug w/ --backup-dir or --backup option?
By the way, if it makes a difference, our backup-dir is on a different partition than the destination directory. I'm not sure if --backup permissions/ownership are preserved properly if done on the same partition. Carey -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Carey Jung Sent: Wednesday, September 19, 2001 12:38 AM To: rsync list Subject: permissions bug w/ --backup-dir or --backup option? Running rsync 2.4.7pre1, using the --backup-dir option, I just realized today that file ownerships and permissions of backed up files are not preserved. In other words, if rsync moves an obsolete file to the backup dir, it's ownership seems to revert to root:root, and permissions change, as well. We are also using the -a (archive) option, by the way, which should mean preserve everything. This loss of ownership/permissions seems like a definite bug to me. What do you think? Regards, Carey Jung IT Freedom
