partial-dir not being used?!

[Carlos Carvalho]

Wayne Davison (wayned at samba.org) wrote on 22 August 2009 09:15:
 >On Fri, Jul 17, 2009 at 02:13:00AM -0300, Carlos Carvalho wrote:
 >> There can be several partials in the partial dir for the same file,
 >> resulting from more than one interruption.
 >
 >No, there is only one partial file.  Don't confuse a partial file with a
 >temp file, which are different things in rsync's nomenclature.

Yes, I discovered it :-)

 >> What happens if we set temp-dir the same as partial-dir?
 >
 >Rsync does not currently support a relative temp-dir if it does not
 >exist in each directory.

Also found it. Further, if temp-dir is a relative path it's taken
relative to the destination, which means that if we use --tempdir=.
all temp files are created in the root of the destination, not in the
same dir as the file, which it does if temp-dir is not given... It
makes sense but is rather subtle and should probably be explained in
the manual.

 >It would be possible to change this so that
 >rsync goes around creating a relative temp dir for every dir that needs
 >a transfer (and removing it afterwards), but the current code doesn't do
 >that.  (It only creates a missing dir if the transfer gets interrupted
 >and it needs to save a partial file into the --partial-dir.)

I was arguing with Matt that rsync should put the temp file in the
partial-dir if it is defined (and do as it does now if not defined).
The reason is that if rsync is forcibly killed or the machine crashes
the single temp file will be left for ever. Of course one can do a full
recursive scan with delete, but you know how expensive this is for
large trees.

If we want to avoid the full scan we have to search for a file with a
random unknown name... If we knew it was in a partial-dir we could
just scan these; they have few files, so stat()ing is fast. However
rsync puts the temp file in the same dir as the file to be updated,
which has many more files. We have to list that dir instead of the
partial-dir, stat()ing tens of thousands of files instead. Rather
inefficient for recovery...

One can use a fixed temp-dir but if the destination spreads over more
than one mount point we become inefficient for normal operation, which
is worse.