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 > functions. 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! > > Matt > -- Ming Zhang @#$%^ purging memory... (*!% http://blackmagic02881.wordpress.com/ http://www.linkedin.com/in/blackmagic02881 -------------------------------------------- -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html