Preserving overwritten/deleted items

[Grant Jacobs]

This doesn't always work, a point I might start another thread about 
(unless people are happy it being in this thread!). In the meantime 
I'll put it all in here... (excuse the length)

I'm new to rsync. My comments are based on trying thing many options 
on a few test sets. Feel free to let me know if I'm off the mark, 
esp. as this bug (as I see it) seems too obvious to me and surely has 
already been considered (?).

Consider the case of a file of the same name on both the source and 
the destination. If the types are different, rsync tries to overwrite 
the destination file; not an approach I like, but at least its 
documented (although a little buried). What's really bad, fatal IMO, 
is that --backup doesn't do the expected thing in this situation: 
rsync will try to clobber the destination file without making a 
backup or letting you know about it. Not nice.

e.g. if you have a _file_ "tracker" on the source and a _directory_ 
"tracker" on the destination, rsync will try delete the directory 
regardless of what options you give it. I picked this up as on my 
system (OSX 1.4.2), as it fails to remove the directory as its not 
empty and lets you know about its failure to remove it. 
--ignore-existing has no effect in this situation and --backup 
doesn't.

Likewise, if the source has a directory "silly-dir" and the 
destination has a file of the same name, rsync tries to clobber the 
file. In this case, the overwriting happens silently and the old file 
is gone with no warning that its over-written anything or a backup 
being made.

What ought to happen, IMO, is for --backup to make a backup of the 
original file or directory before attempting to copy the new 
file/directory over regardless of the types of the files involved. 
This smells like a simple logic order thing to me: the test for 
needing a backup should be done prior to testing for differing file 
types, etc. (I haven't time to look at the code--sorry, I have to get 
on with finding an alternative solution.)

Assuming this is "for real", some suggestions/wishes to the 
development team (if any of these are already present let me know!):

1. More logging options. Include an option to report _all_ instances 
of over-writing a file regardless the event that causes the 
over-writing.

2. --backup really must work regardless of the types of the files 
involved. Or its not a backup IMO.

3. I'd recommend options for versioned backups. I know the ~ suffix 
has some history, but what happens if you need to backup a file that 
already has a backup? (Aside from appending more tildes.) For that, 
I'd prefer either the VMS-style thing of numbered backups (.1, .2, 
etc) or preferably what I do in my own scripts--use dates 
(.03Sep2005, .04Sep2005, etc). I'd add --numbered-backup-suffix and 
--date-backup-suffix, with a --date-format to give the format of the 
date string (use the date command's formats). I know --backup-dir= 
can address this in a sense, but some may prefer a single hierarchy 
to several. Allowing users to enter a date format allows for other 
variants to be created, e.g.:  -rsync-dup.23Oct05


Enough to keep you going? ;-)


For another topic: --force doesn't seem to work on making rsync 
delete destination directories that have files, at least under OSX 
10.4.2 without --delete et al.


Grant


>
>Re: Preserving overwritten/deleted items
>
>Wayne Davison
>Sat, 24 Sep 2005 12:04:01 -0700
>
>On Sat, Sep 24, 2005 at 12:15:27PM +0200, Christoph Biedl wrote:
>>  I'd like to keep a copy of these files/links/whatever. Is there a way to
>>  create a copy of them in another tree right before they are purged?
>
>See the --backup option.  It applies to more than just deleted items,
>though, but also changed items.
>
>..wayne..

-- 
-------------------------------------------------------------------
Grant Jacobs Ph.D.                                     BioinfoTools
ph. +64 3 478 0095  (office, after 10am)               PO Box 6129,
or  +64 27 601 5917 (mobile)                               Dunedin,
gjacobs at bioinfotools.com                               NEW ZEALAND.
    Bioinformatics tools: deriving knowledge from biological data
Bioinformatics tools - software development - consulting - training
Check out the website for more details: http://www.bioinfotools.com

The information contained in this mail message is  confidential and
may be legally privileged.  Readers of this message who are not the
intended recipient are hereby notified that any use, dissemination,
distribution or reproduction of this message is prohibited.  If you
have received this message in error please notify the sender immed-
iately and destroy the original message.  This applies also to  any
attached documents.
-------------- next part --------------
HTML attachment scrubbed and removed