Difference in behaviour with --backup
bet at rahul.net
Wed Feb 26 02:16:09 EST 2003
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
/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
(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
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 \
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/rsync/attachments/20030225/cdfcbd6e/attachment.bin
More information about the rsync