Preserving overwritten/deleted items

[Grant Jacobs]

>On Mon, Oct 03, 2005 at 10:54:20PM +1300, Grant Jacobs wrote:
>>  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.
>
>Of course -- it has to remove a directory that is in the way of a file
>that it was told to copy.  If --delete or --force was not specified,
>rsync will output an error if the directory is not empty.  If the
>directory is empty, it's just removed (since an empty directory is not
>considered necessary to backup on its own).  If --delete or --force WAS
>specified, any removed contents are backed up, so it's all working as
>it should.

You seem to be missing the point I was trying to make. I've no 
problem with rsync replacing the directory and of course it has to; 
my problem is with rsync  not making a backup of the directory when I 
apply --backup. The fact its trying to _remove_ the directory, not 
rename it is relevant in this context. (You've deleted all my 
references to making backups in your reply, btw, which removes the 
main point I was after!)


Another try: things works as I'd expect them to for files of the same 
type, so why not for files of different types?

Surely, it'd be simpler and more useful to make it so that any time 
content on the destination is to be replaced, that files involved are 
renamed to be a backup, then rsync copies the replacement over?

I can't see any reason the rule has to be different because the files 
have different types. I'd like to think I'm not the only user 
considers the concept of --backup is that "if some content is going 
to be replaced, rsync will retain a backup copy." (Note there is 
nothing about file types in that statement; the key to the logic is 
that files have to be replaced and hence ought to be backed-up, not 
what the types the files have.)

As things stand the statement in the man page:

  -b, --backup
         With  this option preexisting destination files are renamed with
         a ~ extension as each file is transferred.  You can control  the
         backup suffix using the --suffix option.

isn't _always_ true, in some situations the destination file is 
(silently) removed  even with --backup on. It wasn't clear (to me) 
from the man page that this is the expected/current behaviour. As I 
understand it, the current situation is closer to:

  -b, --backup
     With  this option preexisting destination files OF THE SAME TYPE as a
     file on the source are renamed with a ~ extension as each file is
     transferred.
     If the source and destination files are of different type, rsync will
     attempt to remove the destination (no warning is logged) without making
     a backup copy. If the destination is a directory containing files, the
     removal may fail, in which case the source file is not transferred.
     If an empty directory is encountered, this too will be removed without
     logging.

Personally, I'd prefer the action:

   If a conflict exists, the conflicting destination file is renamed to have
   the backup suffix, then the replacing file is copied from the source.

Its simpler and more consistent (to me anyway...) At the very least, 
could the man page be expanded to reflect what actually happens so 
(pickier!) people like me are warned?


FWIW, at least one other sync program I've viewed since does catch 
the file/directory conflicts I posted.


>>an empty directory is not
>considered necessary to backup on its own

This isn't good behaviour IMO. Your man page asks for opinions, this 
is mine ;-)
If something is going to be removed, it should be backed-up under 
--backup regardless. Some scripts/program expect directories to be 
present, even if they happen to be empty. Likewise, some directories 
temporarily end up empty (e.g. cache directories, download locations, 
etc.)


>  > 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.
>
>You seem to be trying to make that sound bad, but rsync needs to update
>the file to its new status as a directory.

I'm not "trying to make that sound bad", I'm stating how it is (I'm 
using clobber in the Unix sense of [no]clobber and excuse my silly 
filenames, I get bored...). Please consider that you're missing my 
point before smearing me! ;-)  Of course it needs to update it do a 
directory, I never said it didn't. What I did say was that it ought 
to backup the file its replacing if --backup is used, but it doesn't. 
The issue is the lack of backups, not the replacing. (Warnings of 
replacements might help too, hence one of my suggestions.)


To close, I wasn't trying to take potshots at rsync as some might 
read in your reply, but rather raise an scenario where some users 
lose data in the hope that it might be useful to the development 
team. Criticism can be hard to take I know, but I was hoping it'd 
help to make it a better product.

It does bother me as rsync is used as the underlying method in many 
backup schemes, yet it in particular circumstances with --backup on, 
it silently overwrites files without making a backup which some 
people might not be expecting. Since that will affect others, I 
thought to post it.

Admittedly I'm too picky to put up with "the odd quirk" in backup 
software ;-), so personally I'm glad I picked this up before I 
started using it in a production fashion.


Grant
-- 
--------------------------------------------------------
Grant Jacobs                   grant.jacobs at clear.net.nz
Dunedin,                              ph. +64 3 478 0095
NEW ZEALAND.                         fax. +64 3 470 0095