what is the right exit code for some vanished files?
blackmagic02881 at gmail.com
Sun Dec 23 20:55:15 GMT 2007
On Thu, 2007-12-20 at 10:24 -0500, Matt McCutchen wrote:
> 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
if sender read by path again and get ENOENT, then this ENOENT can tell
rsync enough info. (though current rsync might say partial transfer
though it is a vanished file... )
> this, the sender could read the xattrs through the fd using the f*xattr
yes, all operation base on opened fd will be better to keep the
correctness property you mentioned.
all file sync/backup software for a live file system can have same issue
here. which state to maintain. rsync can always do a stat on the saved
path again after the transfer, to detect the change, and then (with an
option specified), put the path into a residual file list and reprocess
them again. but maybe rsync does no need to go this far and a higher
layer software base on rsync can do this...
Thanks a lot for all the explanation and wish you a happy holiday!
@#$%^ purging memory... (*!%
More information about the rsync