Bug 12367 - temporary lines in --progress output are not cleared
temporary lines in --progress output are not cleared
Status: RESOLVED FIXED
Product: rsync
Classification: Unclassified
Component: core
3.1.2
All All
: P5 minor
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-10-07 12:20 UTC by Paul Slootman
Modified: 2016-10-29 22:33 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 Paul Slootman 2016-10-07 12:20:17 UTC
A bug report received by Debian (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749165). I can verify this. 
emit_filelist_progress() in flist.c needs something like a "output_needs_newline_maybe" variable... I can't quite see how to implement that cleanly.

>>---

Some temporary lines output by --progress are not cleared, so that
the output looks strange. Here's a testcase.

------------------------------------------------------------
#!/bin/sh

set -e

export LC_ALL=C
t=$HOME/rsync-test
mkdir "$t"
cd "$t"

if [ ! -d a1 ]; then
  mkdir a1
  touch a1/foo
fi

if [ ! -d a2 ]; then
  mkdir a2
  for i in `seq 1 250`
  do
    mkdir -p a2/dir$i
    for j in `seq 1 20`
    do
      mktemp --tmpdir=a2/dir$i > /dev/null
    done
  done
fi

mkdir b
for i in 1 2
do
  mkdir -p c/a$i
  ln -ns ../c/a$i b
done

rs()
{
  rsync -KRt "$@" a2/*/* a1/foo "localhost:$t/b/"
}
rs
rs --progress
rm -r "$t"
------------------------------------------------------------

I get:

a1/00 files...
a2/

(sometimes without the "a2/" line).

If I redirect the output to some file, I can see with "less":

 0 files...^M 400 files...^M 2500 files...^M 4600 files...^Ma1/
a2/

The problem is that when "a1/" is output, the previous " 4600 files..."
line was not cleared and one can still see the end of it.

<<---

I can verify this.
Comment 1 Andrey Gursky 2016-10-08 00:19:05 UTC
Hi Paul,

you reported something similar on the list (https://lists.samba.org/archive/rsync/2015-December/030478.html). I've instantly recalled that, because this issue also annoys me. If I redirect rsync output via pipe and tee the resulting file is polluted with percentage progress info.

Regards,
Andrey
Comment 2 Wayne Davison 2016-10-29 21:39:46 UTC
This is apparently only happening with no -r combined with --progress. In this case there can be a series of file-count outputs (with CR) prior to the start of the transfer, but no LF before it moves on to other output.

Git commit e02b89d0d fixes this.
Comment 3 Wayne Davison 2016-10-29 22:33:52 UTC
Actually, I diagnosed this further, and noticed that the file counts shouldn't be output at all -- the check for progress output was being fooled by a temporary setting of the xfer_dirs var when -R is used without -d or -r.  I've changed the show_filelist_p function into a var that is set during the init call so that it is always evaluated the same way.

This git commit also contains a fix for the newline that could get output with --quiet: ff66fd4bb