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 [EMAIL PROTECTED]
Dunedin, ph. +64 3 478 0095
NEW ZEALAND. fax. +64 3 470 0095
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
