Bug 6741 - 'deleting' messages show up in improper places
Summary: 'deleting' messages show up in improper places
Status: RESOLVED WONTFIX
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.0.5
Hardware: x86 Linux
: P3 normal (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-17 09:24 UTC by ascheel
Modified: 2024-10-25 15:17 UTC (History)
1 user (show)

See Also:


Attachments
rsync stdout filter (15.21 KB, text/plain)
2024-02-29 21:26 UTC, Marc Aurèle La France
no flags Details
rsync stdout filter (16.88 KB, text/plain)
2024-08-29 20:32 UTC, Marc Aurèle La France
no flags Details
rsync stdout filter (18.32 KB, text/plain)
2024-10-25 15:17 UTC, Marc Aurèle La France
no flags Details

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?
Comment 4 Wayne Davison 2020-07-28 00:22:03 UTC
I'm not inclined to change this.
Comment 5 Marc Aurèle La France 2024-02-29 21:26:04 UTC
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.
Comment 6 Marc Aurèle La France 2024-08-29 20:32:27 UTC
Created attachment 18425 [details]
rsync stdout filter

vee too
Comment 7 Marc Aurèle La France 2024-10-25 15:17:14 UTC
Created attachment 18484 [details]
rsync stdout filter

Checkpoint III