sorry about the delay getting back to you on your considered reply,
sorry to see that this question has been asked before
(http://lists.samba.org/pipermail/rsync/2001-September/004877.html)
and sorry for this basically frivolous reply:
i guess my take is that, if the user requested preservation of per-
missions, then that may be what the user is expecting with respect
to backup-hierarchy recreation also. (i'll admit, for the record,
that *this* user was.) it could be sort of an unpleasant surprise,
at any rate, to find out that some file that one of your users hadn't
properly sured up permissions on but had been securely buried in a
hierarchy of drwx***--- directories had suddenly been made available
for public consumption by your backup regimen
so, far removed from any profiling considerations (which you can
correctly assume i'm unqualified to comment on), i guess what i'm
asking is that you Think About The Children--urrh, humble, unwit-
ting users like me, who would rather have butt-coverage than speed
in this regard and who wouldn't hold backup-futzing against rsync's
speed rep, especially if you gave us an option like
--slow,secure-backup-dir-permission-preservation
to warn us (and our weary typing fingers) away
thanks again, and wishing everyone also a Merry Christmas and Happy
New Year, if you observe those around this time, but Blessing and
Peace in any case
--buck
P.S.--for the record and on the subject of hobbling rsync, JMC
updated the ACL patch at http://www.lpmd.org/rsync-2.5.5-acl.diff.gz
to preserve ACLs on --backup -ed stuff. thanks, JMC, and caveat usor
On Mon, Dec 16, 2002 at 04:00:53PM -0600, James Delahanty wrote:
Buck,
You have a good point about make_bak_dir(), and pose a good question...
With the --backup-dir switch, any file *or directory* that is destined
for deletion is saved to the backup directory. A file is deleted by
rsync whenever it is actually deleted on the sync system (obviously!),
or when it is replaced by a file with the same name/different rsync
signature as part of the rsync process. All files or directories that
fall under this umbrella are saved to the backup-dir with their original
permissions intact.
The interesting question is: What do we do with directories that we must
manufacture to position the files in the right place in the
backup-dir?
My take was: Completely ignore the permissions of these directories,
unless they were deleted (see above), and use the robust_move()
function already in backup.c to move the file/create the directories as
needed (perms: 0755). This was done strictly for speed. The win: Fast,
no hassle path creation. The lose: Created path does NOT have same
permission as original path to file -- but the individual file
permissions are correct. This was an acceptable tradeoff for our
purposes, but YMMV. I can certainly understand (and appreciate) that
it's an unacceptable tradeoff to some.
Personally, I prefer that this shortcut be left as is, or be (yet
another) compile-time option. (-DKEEP_ALL_BK_DIR_PERMS), but I'm not a
maintainer, just a contributor. (You might like to profile the change,
though, just to see the kind of hit you take. IIRC, it was pretty
significant.)
P.S. -- Many thanks to the Rsync team, Merry Christmas and Happy
Holidays!
Regards,
Jim Delahanty
Date: Mon, 9 Dec 2002 17:13:15 -0500
From: Buck Huppmann [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: when using --backup-dir: why not make_bak_dir() . . .
here (in keep_backup())?
--- backup.c.orig Mon Dec 9 17:02:36 2002
+++ backup.cMon Dec 9 17:03:50 2002
@@ -273,6 +273,7 @@
/* move to keep tree if a file */
if(!kept) {
+ make_bak_dir(fname,backup_dir);
if (!robust_move (fname, keep_name))
rprintf(FERROR, keep_backup failed %s - %s : %s\n,
fname, keep_name, strerror(errno));
this reconstructs parent directory permissions more in keeping with
my (humble) expectations, in addition to being consistent with the
way all ~S_IFREG links' parents are produced
just curious
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
