Bug 2554 - Output overwrite action
Summary: Output overwrite action
Status: CLOSED WORKSFORME
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 2.6.4
Hardware: All Linux
: P3 enhancement (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-03-29 06:11 UTC by Martin Jeppesen
Modified: 2005-04-01 11:25 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 Martin Jeppesen 2005-03-29 06:11:53 UTC
When using --dry-run between two locals disks, rsync outputs the files that will
deleted and copied/overwritten.

If a file will be deleted the line starts with "Delete", but when a file will be
copied or overwritten, nothing is displayed.

So I would like to suggest, that when a file will be overwritten, rsync writes
"Overwrite" at the start of the line, and when new files are copied, rsync
writes "Copy".

This would be very useful, as I review the list before I do the back up, and
with this feature, I would be able to grep in the list for data that will be
lost (deleted or overwritten).
Comment 1 Wayne Davison 2005-03-29 11:50:27 UTC
(In reply to comment #0)
>> If a file will be deleted the line starts with "Delete", but when a
> file will be copied or overwritten, nothing is displayed.

I assume you mean, "no prefix is displayed" since there is something that is
displayed: the filename.  Sounds like you want the new -i option.  Give it a try.
Comment 2 Martin Jeppesen 2005-03-29 12:37:05 UTC
I don't think I quite understand the -i option. The manpage doesn't cover it yet.

If I try this:
rsync -avRxin --delete rsync-2.6.4pre4 rsync-2.6.4pre42|less

where I have deleted the NEWS file and altered the README file.

This gives me:
building file list ... done
cd+++++++ rsync-2.6.4pre4/
<f+++++++ rsync-2.6.4pre4/.ignore
<f+++++++ rsync-2.6.4pre4/COPYING
<f+++++++ rsync-2.6.4pre4/Doxyfile
<f+++++++ rsync-2.6.4pre4/INSTALL
<f+++++++ rsync-2.6.4pre4/Makefile
<f+++++++ rsync-2.6.4pre4/Makefile.in
<f+++++++ rsync-2.6.4pre4/NEWS
<f+++++++ rsync-2.6.4pre4/OLDNEWS
<f+++++++ rsync-2.6.4pre4/README

I was hoping for something like this:

building file list ... done
Copy rsync-2.6.4pre4/NEWS
Overwrite rsync-2.6.4pre4/README
Comment 3 Wayne Davison 2005-03-29 12:53:45 UTC
(In reply to comment #2)
> The manpage doesn't cover [-i] yet.

The release announcement mentioned where both of the manpages are visible online:

http://rsync.samba.org/ftp/rsync/preview/rsync.html
http://rsync.samba.org/ftp/rsync/preview/rsyncd.conf.html

> <f+++++++ rsync-2.6.4pre4/.ignore

These were all new files, so there were no overwrites.  Try overwriting something.
Comment 4 Martin Jeppesen 2005-03-29 13:38:58 UTC
I have now constructed a case, where I ought to see 1 file being deleted and 1
file being overwritten:

test1/file_a      (61 bytes)
test2/file_a      (17 bytes)
test2/file_b      (40 bytes)

~$ rsync -avRxWin --delete test1/ test2/
building file list ... done
cd+++++++ test1/
cd+++++++ test1/./
<f+++++++ test1/file_b

Because of --delete I would expect rsync to delete test2/file_b as it doesn't
excist on the sender.

Because file_a have a different file size, I would exspect rsync to overwrite
this file.

Is this correct understood?

I have put the testcase up at:
www.heko.dk/~maj/testcase.tar
Comment 5 Wayne Davison 2005-03-29 14:44:33 UTC
Get rid of the -R option -- it is tripping you up.
Comment 6 Martin Jeppesen 2005-03-29 15:35:00 UTC
This is excellent! Thanks=)

~$ rsync -avxWrn --delete --log-format='%i %f' test1/ test2/
building file list ... done
*deleting file_a
.d..t.... test1/.
<f.st.... test1/file_b

In this case I can see that the file size have changed, but not if the source
file have changed to e.g. zero bytes, which probably would be bad.

Would the following escapes be a good idea to implant?:

%sc   source file checksum
%dc   destination file checksum
%ss   source file size
%ds   destination file size

And finally. My I suggest that send symbol is changed from '<' to '>' ?

My argument for making this suggestion is that the rsync syntex is
rsync [OPTION]... SRC [SRC]... DEST

and having send to be '>' could be translated as an arrow travelling from source
to destination.

Thanks again.

Comment 7 Wayne Davison 2005-03-30 09:27:37 UTC
It would be difficult to implement the log-format escapes you mention because,
at the time that the log-message is output, the destination information may not
be available (e.g. if the sending side is outputting the messages).  There is
already the "%l" (ell) escape for outputting the length of the file being
transferred, so you can see if rsync is going to transfer an empty file.

As for the '<' and '>' symbols, they indicate the direction of the transfer. 
They can't refer to the direction of the names on the command-line because those
names are always in the order SOURCE -> DEST.  If SOURCE is remote, we output a
'>... FILE" message because the information is flowing to the local file.  If
the SOURCE is local we output a '<... FILE" message, because the file is being
uploaded to the destination.  For a local transfer, the latter idiom is used
just because a local transfer is done using a "push", not a "pull" (it might be
nice to make a local transfer output using a '>', though, so that it always
means "written out locally").
Comment 8 Martin Jeppesen 2005-03-30 10:11:55 UTC
The %l solves my concern=)

I have been doing a back up using the %l. Would it be possible to add a fixed
number of digits to output?

E.g. %l6 would output

*deleting      0 file_a
.d..t....   4096 test1/.
<f.st....     61 test1/file_b
<f+++++++     56 test1/file_c

This would make the output in columns, and easy to read.

Sorry for the many suggestions, but it just because I think rsync is so marvelous.

Thank you for the very detailed answer to the < and > symbols. I didn't think
about the case, where rsync is used in a network.

I very much like the idea of > always means "written out locally", as you
explained to me.