The 'deleting' messages below are showing up in the middle of a transfer. It shows files being deleted and the progress bar appears to detail the deleting process. Usually rsync handles files in alphanumeric order, but there are still a number of files to transfer in the Dio directory. Dio/path/file.ext deleting Donovan/folder.jpg deleting Donovan/path/folder.jpg 5046272 51% 78.19kB/s 0:01:01
art@eee1:~$ rsync --version rsync version 3.0.5 protocol version 30 Copyright (C) 1996-2008 by Andrew Tridgell, Wayne Davison, and others. Web site: http://rsync.samba.org/ Capabilities: 64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints, socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace, append, ACLs, xattrs, iconv, symtimes rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the GNU General Public Licence for details.
Yeah, the way things currently work when rsync is deleting files as it goes (ala --delete-during) when pulling files (but not when pushing or making a local transfer), it is the generator that is outputting messages about what got deleted, and the receiver outputting messages about what got transferred, and this can cause the messages to intermix in strange ways. It would be possible to modify protocol 31 to allow a MSG_DELETED to be sent to the sender when it is on the serving side, and have it forward the message on to the receiver, and then make the receiver output about the deletion. That would make the output correct. I will consider such a change for 3.1.0. If someone would like to look into that, feel free to attach a patch to this bug.
(In reply to comment #2) > It would be possible > to modify protocol 31 to allow a MSG_DELETED to be sent to the sender when it > is on the serving side, and have it forward the message on to the receiver, and > then make the receiver output about the deletion. Careful: that allows a malicious sender to lie to the receiving side's log about what files were deleted. On second thought, we may have the same issue for attribute tweaks, or any other change performed by the generator. Are those currently logged by the generator or passed around to the receiver?
I'm not inclined to change this.
Created attachment 18263 [details] rsync stdout filter Just something I've come up with to work around this issue. Not perfect but does the job. See usage information in the comments.