Red Hat Bugzilla – Bug 165704
Rsync ignores --backup if --delete-after is included
Last modified: 2014-08-31 19:27:49 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
If using rsync for backups with snapshot incrementals, deleted files will not be backed up.
Version-Release number of selected component (if applicable):
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
Reccomend upgrade to at least 2.6.5, fixing:
- 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
- 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
- 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
- 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
- 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
- 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
- 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).
I think this is now fixed -- FC4 rsync was updated to 2.6.8 in May. Please
reopen if I'm incorrect.