Bug 6741 - 'deleting' messages show up in improper places
'deleting' messages show up in improper places
Status: ASSIGNED
Product: rsync
Classification: Unclassified
Component: core
3.0.5
x86 Linux
: P3 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-17 09:24 UTC by ascheel
Modified: 2009-09-20 21:00 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ascheel 2009-09-17 09:24:09 UTC
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
Comment 1 ascheel 2009-09-17 09:24:55 UTC
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.
Comment 2 Wayne Davison 2009-09-20 16:02:24 UTC
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.
Comment 3 Matt McCutchen 2009-09-20 21:00:56 UTC
(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?