Bad size transfers

[Juan Pablo Lorier]

Hi Wayne,

I assume the file is completed by the time rsync started copying, but it
may happens that another file creation triggered the rsync before the
last one was copied and in that case, the scenario you described is
possible.
I'll try to enhace my script not to sync everything and to update rsync
also.
Thank you very much.
Regards,

On 27/11/13 04:20, Wayne Davison wrote:
> On Tue, Nov 26, 2013 at 5:57 AM, Juan Pablo Lorier <jplorier at gmail.com
> <mailto:jplorier at gmail.com>> wrote:
>
>     I see by the logs that files are partially transferred and deleted
>     from source (as specified by the flag) but destination file is far
>     from a copy of the original.
>
>
> Are those files possibly copied before they are done being written?
>  The best way to orchestrate a setup like that is to move fully-formed
> files into the dir where rsync will copy+delete them (i.e. create them
> in a different folder on the same mount and rename them).  Rsync 3.1.0
> has a change that tries to help people who don't follow that
> best-practice rule:  if the sender's file does not have the same size
> and modify time at delete time as it did when it was originally
> scanned, the remove request is skipped and rsync outputs an error message:
> ERROR: Skipping sender remove for changed file: foo
> If you're using an older rsync, you might try compiling the latest git
> version (or "nightly" tar file) and see if that extra check helps you
> (make sure at least the sending side has the new code).
>
> ..wayne..

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/rsync/attachments/20131127/03731d2e/attachment.html>