rsync deleted all my important docs...

Matt McCutchen matt at
Mon Sep 14 16:15:49 MDT 2009

On Mon, 2009-09-14 at 10:30 -0300, Carlos Carvalho wrote:
> Matt McCutchen (matt at wrote on 13 September 2009 16:53:
>  >On Sat, 2009-09-12 at 18:22 -0300, Carlos Carvalho wrote:
>  >> Sanjay Acharya (svacharya76 at wrote on 11 September 2009 11:02:
>  >>  >How is rsync supposed to behave when I give the --delete-excluded?
>  >> 
>  >> >From the manual for the --delete option:
>  >> 
>  >>    If the sending side detects any I/O errors, then the deletion of
>  >>    any files at the destination  will  be  automatically  disabled.
>  >>    This  is  to  prevent temporary filesystem failures (such as NFS
>  >>    errors) on the sending side causing a massive deletion of  files
>  >>    on   the   destination.
>  >
>  >Unfortunately, this safety feature is partially disabled when rsync uses
>  >protocol 30 (default for rsync 3.0.*) with incremental recursion and
>  >--delete-during, because it caused a deadlock that could not be fixed
>  >without breaking protocol compatibility; see commit
>  >deea1f70bd67c6cc9249def9164f5e61e786e845 .
> Searching in the gitweb I didn't find this commit. How can I discover
> it?;a=commit;h=deea1f70bd67c6cc9249def9164f5e61e786e845

That commit was the one I remembered seeing on the 3.0.x branch; it
removed the safety check once the deadlock was discovered.  I did a "git
log -Scheck_for_io_err" on the trunk, finding that the feature was added
in the same problematic form and then changed to the working version for
protocol 31:

commit 8b3e60523aa3d86583a1df54c81c9d480ea19740
Author: Wayne Davison <wayned at>
Date:   Sun Aug 31 09:03:50 2008 -0700

    Improved the fix that ensures that the generator gets notified about an
    I/O error for the incremental directory that generated the error.  The
    PROTOCOL_VERSION was bumped to 31 to implement this.

commit f303b749f2843433c9acd8218a4b9096d0d1bb8d
Author: Wayne Davison <wayned at>
Date:   Sat Aug 2 09:14:36 2008 -0700

    Added logic to the receiving side to ensure that the --delete-during
    code will not delete in a directory prior to receiving an I/O error
    for that directory (or not receiving it, as the case may be).

> Also, I see no mention of this in the changelog.

Indeed, there is none.  There probably should be one.

> What's the exit status in this case? From what Sanjay says:
> Sanjay Acharya (svacharya76 at wrote on 11 September 2009 11:02:
>  >rsync: readlink_stat("/mnt/raid-backup/Documents/Finance") failed:
>  >Input/output error (5)
> it appears to be 5. Could it be 23 as well? 23 is very frequent and
> usually not a problem.

23 means that the run completed with at least one nonfatal error that
may affect its correctness.  Such errors can range from inability to set
the mtime of a destination directory owned by someone else to
nonexistence of an entire source argument, and the severity of a
particular error may depend on the use case.  So I would hesitate to
make generalizations.

The "Input/output error (5)" is an errno, which has no relationship to
rsync exit codes.  The error you cited would raise code 23, and
moreover, since it can result in the omission of source files from the
file list, it would set IOERR_GENERAL to suppress deletion.


More information about the rsync mailing list