[Bug 1925381] Re: rsync conceals file deletions from reporting when --dry-run --remove-source-files are used together
Utkarsh Gupta
1925381 at bugs.launchpad.net
Fri Apr 23 16:48:36 UTC 2021
Hi Bill,
Such bugs are worth reporting upstream and once they're fixed there, we
can pick it from there and provide it via the packages we ship, as
exactly what Paride mentioned.
Since you don't want to open an issue upstream, maybe you'd like to use their mailing lists?
cf: https://rsync.samba.org/lists.html
That said, I am marking this as "Invalid" here because of the above
reasons. Thanks!
** Changed in: rsync (Ubuntu)
Status: Triaged => Invalid
** Changed in: rsync (Ubuntu)
Status: Invalid => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to rsync in Ubuntu.
https://bugs.launchpad.net/bugs/1925381
Title:
rsync conceals file deletions from reporting when --dry-run --remove-
source-files are used together
Status in rsync package in Ubuntu:
Won't Fix
Bug description:
Rsync has an astonishing and dangerous bug:
The dry run feature (-n / --dry-run) inhibits reporting of file
deletions when --remove-source-files is used. This is quite serious.
People use --dry-run to see if an outcome will work as expected before
a live run. When the simulated run shows *less* destruction than the
live run, the consequences can be serious because rsync may
unexpectedly destroy the only copy(*) of a file.
Users rely on --dry-run. Although users probably expect --dry-run to
have limitations, we don't expect destructive operations to be under
reported. If it were reversed, such that the live run were less
destructive than the dry run, this wouldn't be as serious.
Reproducer:
$ mkdir -p /tmp/src /tmp/dest
$ printf '%s\n' 'yada yada' > /tmp/src/foo.txt
$ printf '%s\n' 'yada yada' > /tmp/src/bar.txt
$ cp /tmp/src/foo.txt /tmp/dest
$ ls /tmp/src/ /tmp/dest/
/tmp/dest/:
foo.txt
/tmp/src/:
bar.txt foo.txt
$ rsync -na --info=remove1 --remove-source-files --existing src/* dest/
(no output)
$ rsync -a --info=remove1 --remove-source-files --existing src/* dest/
sender removed foo.txt
$ ls /tmp/src/ /tmp/dest/
/tmp/dest/:
foo.txt
/tmp/src/:
bar.txt
(*) note when I say it can destroy the only copy of a file, another
circumstance is needed: that is, rsync does not do a checksum by
default. It checks for identical files based on superficial
parameters like name and date. So it's possible that two files match
in the default superficial comparison but differ in the actual
content. Losing a unique file in this scenario is perhaps a rare
corner case, but this bug should be fixed nonetheless. In the typical
case of losing files at the source, there is still a significant
inconvenience of trying to identify what files to copy back.
Note this bug is similar but differs in a few ways:
https://bugzilla.samba.org/show_bug.cgi?id=3844
I've marked this as a security vulnerability because it causes
unexpected data loss due to --dry-run creating a false expectation.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1925381/+subscriptions
More information about the foundations-bugs
mailing list