DO NOT REPLY [Bug 3461] rsync is not atomic when temp-dir is on different device

[bugzilla-daemon at dp3.samba.org]

https://bugzilla.samba.org/show_bug.cgi?id=3461





------- Comment #1 from hashproduct at verizon.net  2006-01-28 14:19 MST -------
I don't see how using a --temp-dir on a different device could make the
transfer faster, if indeed it does.  At some point, all of the data of file.dat
must go from memory to disk 1.  Using a --temp-dir on a different device, with
or without your proposed atomicity fix, does not avoid this bottleneck; after
the additional round trip to and from disk 2, the data must be written to disk
1 as before.

This bug brings up an interesting point.  I wasn't aware that robust_rename
copied files between filesystems when necessary, and I don't think it should. 
Copying data into an existing destination file has the same potentially
undesirable characteristics as --inplace, not least of which is non-atomicity,
but the user is never warned.

If the temp dir is on a different filesystem from the eventual location of a
destination file, what should rsync do?  Ignoring the temp dir and using a
temporary file next to the destination could be hazardous because some users
use a secure temp dir to avoid races in an insecure destination directory. 
Using two temporary files, one in the temp dir and one next to the destination,
is strictly worse than using a single file next to the destination, unless the
disk performance is anomalous like yours.

The current behavior of copying into the existing destination file should only
be used if the user is aware of the consequences.  To specify that she is, she
could give --inplace in addition to --temp-dir=XXX; the sole effect of
--inplace would be to allow this behavior.  If --temp-dir is given without
--inplace and this situation arises, I think rsync should produce an error,
skip the file, and say "some files could not be transferred".


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.