what is the right exit code for some vanished files?

Matt McCutchen matt at mattmccutchen.net
Thu Dec 20 15:24:29 GMT 2007

On Wed, 2007-12-19 at 22:25 -0500, Ming Zhang wrote:
> so this file-list is the internal file list, not the --files-from
> content.

Yes, the correctness property is based on the internal file list.

> rsync's goal is to keep src and dest in same state (same content, or the
> fact that none side has this object) WHEN it process one particular
> object. so if a file is added to file list, just means rsync need to
> maintain same state when it handle that file at that moment,

That's hard to do because rsync has no way to capture the entire state
of the source file atomically.  Instead, rsync tries to satisfy the
correctness property for each individual aspect of the file: its
existence, its stat information, its target path (if a symlink), each of
its POSIX ACLs, each of its xattrs, and each byte of its data.  If
multiple concurrent modifications are made to the source file during the
run, any subset of them could show up on the destination.

> let us say
> rsync copy half the content and then file vanished, then rsync should
> detect the new state of this file (deleted) and delete the dest/A as
> well...

In this case, the sender's fd on src/A will remain open despite the
deletion and the sender will successfully read out the rest of the
pre-deletion content.  The end result is that dest/A reflects the
pre-deletion state of src/A , which is fine.

However, there may be other similar cases that rsync handles poorly.
For example, if src/A vanishes after the sender opens it for reading but
before the sender obtains its abbreviated xattr values, it appears that
the sender will give an error that the xattrs can't be read; to avoid
this, the sender could read the xattrs through the fd using the f*xattr


More information about the rsync mailing list