<div class="gmail_quote">On Wed, Aug 10, 2011 at 3:19 PM, Andrew Gideon <span dir="ltr"><<a href="mailto:c182driver1@gideon.org">c182driver1@gideon.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
So...what is the point of fixing the seed?<br></blockquote><div><br></div><div>I'ts not really intended for normal use.  It can help with some types of debugging and other fringe uses.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Is there a "best solution" for caching checksums?</blockquote><div><br></div><div>For use with user-changeable files (as apposed to things like mirror files that don't change in unpredictable ways), my favorite patch is db.diff -- it allows you to cache checksums in a SQLite or MySQL db.  If you copy files to/from temporarily-mounted filesystems, you will need to update the "disk" table to match the mounted devices each time that changes or just leave out the temp-mounted disks (which will just not cache checksums associated with a missing disk device number).  If your mounts don't vary, a single-time db init via the perl script is all you need (perldb --db=foo.cfg --init --mounts).</div>
<div><br></div><div>I also recommend using the mysql db support unless you're just trying things out, in which case the SQLite support can be somewhat useful.  The SQLite DB likes to do a lot of exclusive locking, and so it is pretty slow when writing lots of checksums.  It can also not play nice with a local transfer where you want both the sender and receiver to be querying and updating the DB at the same time.</div>
<div><br></div><div>Note also that each side of the transfer needs its own --db option, which is why the patch expects the --remote-option (-M) patch to be applied first.  e.g. rsync -aiv --db=/etc/db.cfg -M--db=/etc/db.cfg src/ dest/</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I'm unclear how caching checksums doesn't cause exactly that problem (since a cached checksum means that the file isn't checked for changes each time rsync runs).<br>
</blockquote><div><br></div><div>This works because the caching makes a note of the file's ctime (in addition to size and mtime), which is something like an inode change time.  Any change to a file (data or otherwise) will affect the file's ctime, and the ctime can't be manually set. The caching patches will re-compute the file's checksum if the ctime has changed, just in case the data has changed (and, if the patch saves the info, like db.diff does, it will then note the new ctime when caching the checksum).  Sadly the code doesn't yet save & compare sub-second timestamps (for those filesystems that support that).</div>
</div><br>..wayne..<br>