From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] replica (was: ipv6) From: rsc@plan9.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Tue, 28 May 2002 17:28:44 -0400 Topicbox-Message-UUID: 9ed3da58-eaca-11e9-9e20-41e7f4b1d025 > The file is consistent but is the directory? I.e. if I was copying over a whole bunch of files, > could he not have gotten in when I was half way through? Pull doesn't walk the entire file system looking for changes. Instead, it relies on changes being listed in a change log /n/sources/dist/replica/plan9.log. If I run a pull (so I'm up-to-date) and then you change files on sources, future pulls won't notice any of them until they're added to the change log. The change log gets updated by running mk scan in /sys/lib/dist. This happens half-hourly via cron. If the cron job happened while the copy was in progress, then yes, until the next scan you'd only get half the new files. If the cron job didn't exist, so that mk scan couldn't happen while you were halfway through updating things, then there'd be no way for me to get just some of the changes if I were up-to-date except for those changes. I guess my point in all this was that you cannot get into a state where the client machine has the wrong idea of what it has and doesn't have. For example, a priori you might worry that if I copy down a file as it is changing, I'll get a weird merge of the two files that will persist until the file changes again. Or I'd get the old file but think I had the new one, so that I wouldn't download the new one the next time around. None of those things can happen. Russ