Bug 165704 - Rsync ignores --backup if --delete-after is included
Rsync ignores --backup if --delete-after is included
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: rsync (Show other bugs)
4
All Linux
medium Severity high
: ---
: ---
Assigned To: Jay Fenlason
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-11 09:50 EDT by Ian Young
Modified: 2014-08-31 19:27 EDT (History)
2 users (show)

See Also:
Fixed In Version: 2.6.8-1.FC4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-13 16:52:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Ian Young 2005-08-11 09:50:08 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

Description of problem:
Known bug-- from the 2.6.5 changelog:

"  - Fixed the accidental disabling of --backup during the --delete-after
      processing.
"

If using rsync for backups with snapshot incrementals, deleted files will not be backed up.


Version-Release number of selected component (if applicable):
rsync-2.6.4

How reproducible:
Always

Steps to Reproduce:
1. create a source/dest test tree with files
2. rsync -a the source/dest
3. remove files from source
4. rsync -ab --backup-dir=backup --delete-after source/. dest/.

  

Actual Results:  deleted files were not backed up. --delete-during works (see changelog for 2.6.5)


Expected Results:  deleted files should have been moved to dest/backup

Additional info:

Reccomend upgrade to at least 2.6.5, fixing: 

BUG FIXES:

    - A crash bug was fixed when a daemon had its "path" set to "/", did
      not have chroot enabled, and used some anchored excludes in the
      rsyncd.conf file.

    - Fixed a bug in the transfer of a single file when -H is specified
      (rsync would either infinite loop or perhaps crash).

    - Fixed a case where the generator might try (and fail) to tweak the
      write-permissions of a read-only directory in list-only mode (this
      only caused an annoying warning message).

    - If --compare-dest or --link-dest uses a locally-copied file as the
      basis for an updated version, log this better when --verbose or -i
      is in effect.

    - Fixed the accidental disabling of --backup during the --delete-after
      processing.

    - Restored the ability to use the --address option in client mode (in
      addition to its use in daemon mode).

    - Make sure that some temporary progress information from the delete
      processing does not get left on the screen when it is followed by a
      newline.

    - When --existing skips a directory with extra verbosity, refer to it
      as a "directory", not a "file".

    - When transferring a single file to a different-named file, any
      generator messages that are source-file related no longer refer to
      the file by the destination filename.

    - Fixed a bug where hard-linking a group of files might fail if the
      generator hasn't created a needed destination directory yet.

    - Fixed a bug where a hard-linked group of files that is newly-linked
      to a file in a --link-dest dir doesn't link the files from the rest
      of the cluster.

    - When deleting files with the --one-file-system (-x) option set, rsync
      no longer tries to remove files from inside a mount-point on the
      receiving side.  Also, we don't complain about being unable to remove
      the mount-point dir.

    - Fixed a compatibility problem when using --cvs-ignore (-C) and
      sending files to an older rsync without using --delete.

    - Make sure that a "- !" or "+ !" include/exclude pattern does not
      trigger the list-clearing action that is reserved for "!".

    - Avoid a timeout in the generator when the sender/receiver aren't
      handling the generator's checksum output quickly enough.

    - Fixed the omission of some directories in the delete processing when
      --relative (-R) was combined with a source path that had a trailing
      slash.

    - Fixed a case where rsync would erroneously delete some files and then
      re-transfer them when the options --relative (-R) and --recursive
      (-r) were both enabled (along with --delete) and a source path had a
      trailing slash.

    - Make sure that --max-size doesn't affect a device or a symlink.

    - Make sure that a system with a really small MAXPATHLEN does not cause
      the buffers in readfd_unbuffered() to be too small to receive normal
      messages.  (This mainly affected Cygwin.)

    - If a source pathname ends with a filename of "..", treat it as if
      "../" had been specified (so that we don't copy files to the parent
      dir of the destination).

    - If --delete is combined with a file-listing rsync command (i.e. no
      transfer is happening), avoid outputting a warning that we couldn't
      delete anything.

    - If --stats is specified with --delete-after, ensure that all the
      "deleting" messages are output before the statistics.

    - Improved one "if" in the deletion code that was only checking errno
      for ENOTEMPTY when it should have also been checking for EEXIST (for
      compatibility with OS variations).
Comment 1 Matthew Miller 2006-07-13 16:52:22 EDT
I think this is now fixed -- FC4 rsync was updated to 2.6.8 in May. Please
reopen if I'm incorrect.

Note You need to log in before you can comment on or make changes to this bug.