9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: rsc@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] replica (was: ipv6)
Date: Tue, 28 May 2002 17:28:44 -0400	[thread overview]
Message-ID: <cae5cc9bba0057102d2220bf9ed1819e@plan9.bell-labs.com> (raw)

> 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



             reply	other threads:[~2002-05-28 21:28 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-28 21:28 rsc [this message]
2002-05-28 21:55 ` Chris Hollis-Locke
  -- strict thread matches above, loose matches on Subject: below --
2002-05-28 22:19 rsc
2002-05-28 23:33 ` Micah Stetson
2002-05-28 20:58 presotto
2002-05-28 16:55 rsc
2002-05-28 16:42 forsyth
2002-05-28 15:35 Russ Cox
2002-05-28 16:41 ` postmaster
2002-05-28 15:32 Russ Cox
2002-05-28 15:05 presotto
2002-05-28 12:29 [9fans] ipv6 presotto
2002-05-28 13:26 ` [9fans] replica (was: ipv6) Axel Belinfante

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cae5cc9bba0057102d2220bf9ed1819e@plan9.bell-labs.com \
    --to=rsc@plan9.bell-labs.com \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).