[Touch-packages] [Bug 1925381] Re: rsync conceals file deletions from reporting when --dry-run --remove-source-files are used together
s/Invalid/Won't Fix/g. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1925381] Re: rsync conceals file deletions from reporting when --dry-run --remove-source-files are used together
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 Touch seeded packages, 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1925381] Re: rsync conceals file deletions from reporting when --dry-run --remove-source-files are used together
For me the fact that the upstream repo moved from bugzilla.samba.org to github.com is sufficient to diverge from upstream. But to each his own. My contempt for github is in fact why I reported the bug downstream. I will not use github but I still intended to make a public record of the bug, hence why it's here. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, 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: Triaged 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1925381] Re: rsync conceals file deletions from reporting when --dry-run --remove-source-files are used together
Hello Bill and thanks for this bug report. I can see the issue you described here (thanks for the reproducer), however I believe it should be filed/fixed upstream. Maybe [1] should be expanded to cover --remove- source-files, as the two issues could be related. Diverging from upstream (or from Debian) has a long-term maintenance cost (e.g. rebasing the patch at every release) and can lead to situations which are difficult to handle well: think of a bug that is later fixed upstream but in a different way, with user-facing differences. What to do then, break compatibility with the older Ubuntu releases, or break compatibility with upstream? While I agree this is a bug in my opinion it is not worth diverging from upstream here. I am setting the status of this bug report to Triaged (it is well understood) but with importance: Wishlist. Should you disagree with my reasoning please comment back and change the bug status back to New, we'll look at it again. Thanks! [1] https://bugzilla.samba.org/show_bug.cgi?id=3844 ** Bug watch added: Samba Bugzilla #3844 https://bugzilla.samba.org/show_bug.cgi?id=3844 ** Changed in: rsync (Ubuntu) Status: New => Triaged ** Changed in: rsync (Ubuntu) Importance: Undecided => Wishlist -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, 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: Triaged 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1925381] Re: rsync conceals file deletions from reporting when --dry-run --remove-source-files are used together
** Description changed: Rsync has an astonishing and dangerous bug: The dry run feature (-n / --dry-run) fails to report 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. + 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 parameters like name + and date. So it's possible that two files match in the default + 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. + 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. ** Description changed: Rsync has an astonishing and dangerous bug: The dry run feature (-n / --dry-run) fails to report 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 parameters like name - and date. So it's possible that two files match in the default - 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. + 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. 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. ** Description changed: Rsync has an astonishing and dangerous bug: - The dry run feature (-n / --dry-run) fails to report 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. + 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
