rsync - Mar 2008 - --backup-dir-dels=DIR patch

Hi All,
I think I am missing something with the backup-dir-dels.diff patch.  
How does that differ from the original --backup -backup-dir=DIR  
option? Using the original one works fine (on patched or non-patched  
rsync), putting deleted source files into the DIR on destination, but  
when I run --backup -backup-dir-dels=DIR, nothing happens to the  
deleted files. Rob D

On Sat, 2008-03-08 at 21:52 -0500, Robert DuToit wrote:
> I think I am missing something with the backup-dir-dels.diff patch.  
> How does that differ from the original --backup -backup-dir=DIR  
> option?
It lets you specify a different suffix and/or directory for deleted
destination files as compared to overwritten files.
> Using the original one works fine (on patched or non-patched  
> rsync), putting deleted source files into the DIR on destination, but  
> when I run --backup -backup-dir-dels=DIR, nothing happens to the  
> deleted files.
This is the result of a logic error in the backup-dir-dels patch: it
decides whether to do a simple or parallel-tree backup based on whether
--backup-dir is set, regardless of whether the file in question is being
overwritten or deleted.  Thus, --backup-dir-dels currently only has an
effect if you also specify a --backup-dir.  I will look into getting
this fixed.

Matt

On Mar 8, 2008, at 10:16 PM, Matt McCutchen wrote:
> On Sat, 2008-03-08 at 21:52 -0500, Robert DuToit wrote:
>> I think I am missing something with the backup-dir-dels.diff patch.
>> How does that differ from the original --backup -backup-dir=DIR
>> option?
>
> It lets you specify a different suffix and/or directory for deleted
> destination files as compared to overwritten files.
>
>> Using the original one works fine (on patched or non-patched
>> rsync), putting deleted source files into the DIR on destination, but
>> when I run --backup -backup-dir-dels=DIR, nothing happens to the
>> deleted files.
>
> This is the result of a logic error in the backup-dir-dels patch: it
> decides whether to do a simple or parallel-tree backup based on  
> whether
> --backup-dir is set, regardless of whether the file in question is  
> being
> overwritten or deleted.  Thus, --backup-dir-dels currently only has an
> effect if you also specify a --backup-dir.  I will look into getting
> this fixed.
Ah - got it. thanks, Rob
>
>
> Matt
>

---
This should fix the problem with --backup-dir-dels not working by
itself.

 backup.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/backup.c b/backup.c
index d2a7622..ea53306 100644
--- a/backup.c
+++ b/backup.c
@@ -347,7 +347,7 @@ static int keep_backup(const char *fname)
 /* main backup switch routine */
 int make_backup(const char *fname)
 {
-	if (backup_dir)
+	if (deleting ? backup_dir_dels : backup_dir)
 		return keep_backup(fname);
 	return make_simple_backup(fname);
 }
-- 
1.5.4.3.193.g6dd0e

On Tue, 2008-03-11 at 18:38 -0400, Robert DuToit wrote:
> On Mar 11, 2008, at 12:50 AM, Matt McCutchen wrote:
> > ---
> > This should fix the problem with --backup-dir-dels not working by
> 
> Matt,
> I tried all the patches you posted last night  for dir-dels following  
> these patches:
> 
> patch -p1 <patches/fileflags.diff
> patch -p1 <patches/crtimes.diff
> patch -p1 <patches/fileflags-fixes.diff
> patch -p1 <patches/backup-dir-dels.diff
> 
> but --backup-dir-dels still only seems to work with  --backup-dir  
> included.
That's weird.  The patch worked for me.  If you're doing a remote copy,
make sure you patched the receiving rsync because it's the one that
matters.  If that isn't the problem, please provide your command line
and -vvv output and I'll try to get to the bottom of it.
> Should I have skipped the original backup-dir-dels.diff patch?
No.
> Also I'm sure this isn't possible but I mentioned before the suffix
> option causes Mac package files(applications) to add the suffix to all  
> the resources within and render it useless. Is there a way to add the  
> suffix to just the name of a directory or a file instead of tacking it  
> on to the extension name?
No.  It would not be hard to solve the extension-corrupting problem by
modifying rsync to add the suffix, say, before the last period in the
filename.  More generally, rsync could apply a regular-expression
substitution (s///) to the filename; is there a library that does these?
To handle packages (bundles?) correctly, rsync would also need a list of
name patterns for directories that it should back up "as a whole"
instead of backing up the individual files inside.  Of course, using a
backup dir instead of a suffix avoids the problem entirely.

Matt

On Tue, 2008-03-11 at 21:45 -0400, Robert DuToit wrote:
> I probably missed something  simple... but here is the patching from  
> backup-dir-dels.diff on- I copied your four patches from last night  
> emails exactly into into dirdels.diff, suffixfix.diff, dirdels2.diff,  
> dirdels3.diff, respectively. Was that the right thing to do-run all  
> four?
dirdels.diff is the one that fixes the problem, but running all four is
fine.
> I fixed the options.rej and proceeded to ./configure. Would  
> "malformed patch" be the problem? I included my re-created
patches
> just in case.
The "malformed patch" is almost certainly the problem.  I'll just
send
you the latest backup.c file; that will be faster than fussing with your
email client or patch program.

Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: backup.c
Type: text/x-csrc
Size: 9112 bytes
Desc: not available
Url :
http://lists.samba.org/archive/rsync/attachments/20080311/1018e098/backup.bin