Difference in behaviour with --backup

[Bennett Todd]

Cc-ing this back to the rsync list. Vikas added some more info in
an off-list mail to me, that straightened things out in my mind,
pointing out that if the dst file is specified on the cmdline as
a simple basename, because you've cd-ed to the target dir and are
doing a pull, then rsync does just as with -r --- deposits the
backup copy in --backup-dir with no prefix.

Vikas, that additional info clarifies things for me; I fear you are
out of luck.

Here's the conceptual difference that you're seeing reflected in a
behavior difference, between the two cases.

When you specify, to rsync, that you want to propogate directories
(recursively):

	/path/to/src -> /path/to/dst

(which, BTW, I habitually express as "rsync -a /path/to/src/.
/path/to/dst/", using a trailing /. on the src and a trailing / on
the dst, to make sure rsync and I are in agreement about what's
going where) you've provided rsync with a notion of two-part paths.
The src and dst you provide are tree-roots, and there are a series
of transient paths that rsync generates for itself by recursively
treewalking, within those paths. In this application, rsync deposits
in the --backup-dir copies using just the transient paths, those
generated by rsync's tree-walk; the tree-root prefixes you provide
on the cmdline aren't reflected in subdirectories in --backup-dir.

In the single-file case, you aren't providing rsync with a
separation between a fixed prefix common to all files in the
transfer, and a suffix path generated by tree-walking; instead,
you're providing rsync with two fixed paths. What should it do?

(1) It could use the full names. That's what it does. It's a simple
    rule, and provides the most intrinsic self-documentation of
    "what happened"; it also makes accidental collisions the least
    likely. I believe this is the most conservative choice.

(2) It could do what you want, and take the pure basename of the
    file transferred, using none of the directory prefix of either
    src or dst to try and qualify the filename in the --backup-dir.
    This would arguably be the most harmonious with the behavior
    with recursive tree-copying; but it would also preserve the
    least documentation (in the event of lots of scattered
    single-file copies using a common backup-dir, the various
    prefixes of the copies are lost); and in that same context it
    would maximize the chance that a backed-up file would be
    inadvertently overwritten with another one from a different
    location, because of a shared basename (think common names like
    "Makefile").

(3) It could try and be really clever and deduce a likely desired
    prefix for the backup file by using the longest common suffix
    found between the src and the dst. I could see the case for this
    one, but it'd be so confusing that I'm awfully glad they didn't
    go for it.

There are probably more possibilities that I haven't thought of, as
well.

But I expect that the difference you're seeing --- with recursive
treecopies, files deposited in --backup-dir don't have the
cmdline-specified prefixes preserved, whereas single-file copies do
--- isn't likely to change. You've come up with one work-around;
always do single-file copies as a pull. Even when the dst is on a
remote machine, you can still do that as long as that remote machine
can initiate a connection back to your local one. Suppose you're on
machine "A", and you want to copy A:/path/to/srcfile to
B:/path/to/dstfile, with backup-dir B:/path/to/bckp/. Then you
could, on A, run

	ssh B 'cd /path/to;rsync --backup-dir=/path/to/bckp \
		A:/path/to/srcfile dstfile'

or thereabouts.

If this isn't possible, perhaps because you want to have backup-dir
on the src side, then I think your only alternative may be to
perform your single-file copy as a recursive copy, using --exclude
and --include arguments to narrow down the recursive copy so it only
actually picks up the single file you're interested in. Those args
are a mite tricky, and I can't say I've got them mastered myself,
I'll let someone else advise on how to use them to get what you
want.

-Bennett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/rsync/attachments/20030225/cdfcbd6e/attachment.bin