On Thu, Nov 10, 2005 at 11:30:49AM -0800, Wayne Davison wrote: > On Thu, Nov 10, 2005 at 10:32:50AM -0500, Chris Shoemaker wrote: > > If the original file changes, then so will the hard link. > > No -- an rsync update creates a temporary file, and that file gets > renamed into place, breaking any hard-link that this new code creates. > (The only exception to this update method is when --inplace is enabled, > and I made this conflict with the new --detect-rename option.)
Ah, ok. Perfect. > > If --detect-renames hardlinks the deleted files it doesn't matter that > > the orginals are deleted before transfer; hard drive space is not > > reduced. > > True, but only for correlated files. Any extraneous files will still be > deleted before the transfer. This shouldn't be any worse in disk-space > use than the alternative of not allowing a delete-before pass. I see now. That's a good reason to allow --delete-before. > > Oh, because the match-search for non-missing files is not delayed in > > the --delete-during scan, right? > > Exactly. My text might not have made it clear that this non-missing > handling will always work for files in a single directory (such as > log-dir rotations) as well as files found in the already-scanned dirs > prior to getting to the current directory. That's what I understood, and it's the only thing thing that doesn't feel quite right. Right now, I see the rename-with-replace detection as gravy, since I only envisioned straight rename-with-no-replace at first. But, users are greedy, and they may come to depend on rename-with-replace. It's a little hard to explain that it will only work if the new filepath is lexicographically earlier than the old filepath. Also, see below. > > So, will this be in 2.6.7? > > It has a good chance of making it. It still needs some cleanup and > testing, some of which I've just done: e.g. I've added support for > checksum matching (instead of mod-time matching) when --checksum is > enabled. The aforementioned patch has been updated with the latest > changes. --checksum support is good, but I think it raises the user's expectations even higher about how rsync will perform. It's even *harder* to explain that even with the (more expensive) file checksums, rsync won't use the correct basis for the rename-with-replace case 50% of the time, on average. Is it possible to delay the basis search even for non-missing files if they're not exact matches? -chris -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
