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@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