what is the right exit code for some vanished files?

Matt McCutchen matt at mattmccutchen.net
Thu Dec 20 02:22:10 GMT 2007

On Sun, 2007-12-16 at 13:47 -0500, Ming Zhang wrote:
> > even code 24 is in order because the nonexistence of a --files-from
> > entry cannot affect the correctness of a run with --delete in the way
> > that a traditional vanishing can.
> not quite understand what u meant here...

Sorry.  I was thinking of this comment:


To elaborate:

Rsync generally satisfies the following correctness property: at the end
of a successful run with no concurrent modification of the destination,
every aspect of the destination that is within the scope of the run (as
determined by the file-list and options) reflects a state that the
corresponding aspect of the source had at some time during the run.

Suppose files src/A and dest/A differ.  Suppose we run "rsync -a
--delete src/ dest/" and delete src/A during the run.  To satisfy the
property, rsync should either delete dest/A or fill it with the
pre-deletion contents of src/A.  However, if src/A vanishes after it is
added to the file-list but before the sender can transfer it, rsync
reports src/A as vanished and leaves dest/A alone, violating the
correctness property.  I believe that the code 24 is needed to warn the
user that correctness may have been violated in this way.

On the other hand, if src/A vanishes before it is added to the file-list
(as in the inotify case), rsync deletes dest/A from the destination, so
the run satisfies the correctness property.  Then the only issue is
whether to alert the user that s/he may have mistyped the --files-from
entry.  By default, rsync alerts the user with a code 23.  In the case
of inotify, an option would indicate that this alerting is not desired,
and no exit code would be needed at all.


More information about the rsync mailing list