when using --backup-dir: why not make_bak_dir() . . .

[Buck Huppmann]

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 <buckh at pobox.com>
> > To: rsync at lists.samba.org
> > 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.c    Mon 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
>