[Bug 1925381] Re: rsync conceals file deletions from reporting when --dry-run --remove-source-files are used together

[Bill Yikes]

** 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 *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.
+ 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.

-- 
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:
  New

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