From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] replica From: forsyth@caldo.demon.co.uk MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Wed, 29 May 2002 10:43:03 +0100 Topicbox-Message-UUID: 9f1e2608-eaca-11e9-9e20-41e7f4b1d025 >>Then you have to spend time downloading the >>remote file when most of the time you're going to throw it away >>because the local file _has_ been locally modified. >>I could have included sha1 hashes in the replica(8) metadata. >>Oh well. I expected this not to happen very often, >>and so far have not been proved wrong. the advantage of keeping a hash (eg, md5 or sha1) is that it distinguishes contents of files, which usually is what really matters, whereas modification times and file length by themselves aren't really adequate (in general, in my experience). Qid.path and Qid.vers might do i suppose, but are unique to Plan 9, and even they can change when the contents of a file hasn't actually changed. the hash makes it easier to track versions historically (eg, if i have a file with a given hash code, i can check distribution packages or logs to see whether that file was ever actually distributed as it stands, and if so, when). similarly, if i've got an external replica, i can also use the hash values to relate it to the contents of a (worm) file system dump. there is a risk with hashing of false hits, but perhaps venti suggests that people can be relaxed about that if the hash is peculiar enough. in short, i thought the use of hash values in wrap was a good idea and was surprised it wasn't part of replica!