Re: [9fans] Plan 9 wiping itself?

[sqweek <sqweek@gmail.com>]

On Nov 28, 2007 1:21 PM, Russ Cox <rsc@swtch.com> wrote:
> In this case, replica actually recreates all the files it deletes,
> and it refuses to delete any file that had been locally modified,
> so no information would have been lost.  (I tested this earlier
> today on my own system.)

 Unless of course, replica gets interrupted halfway through on the
client side (not idle speculation, happened to someone on IRC).

> Again, replica won't touch any file that it didn't create
> and it also won't delete any file that has been changed since replica
> put it there.

 Replica not touching any file that it didn't create, while a nice
quality, is not much consolation[1] when it has created the majority
of your system.

[1]ok, it at least means you're not losing any irreplacable files...
unless perhaps you're running on a file server and replica hosed
/bin/^(mount fossilcons venti/sync etc) [2]. in any case, an OS
doesn't earn many brownie points by erasing itself
[2] this is idle speculation

<snip replica changes>
> This will make pull skip over a sequence of
> "delete then recreate" entries in the log.

 The changes sound great, and eliminate my above doomsday scenario...
unless something goes really wrong with the replica log. Is it
replica/updatededb that is the culprit or just the way it is run in
replica/scan? It strikes me that if it is forced to abort for some
reason it should avoid updating the log at all.
 By they way, any idea why the replica/pull -n output is so confusing
in this situation? It lists a lot of "a"s for files which already
exist (eg 386/9pc 386/auth/factotum sys/src/9/boot/boot.h) (in
alphabetic order?), then a lot of "d"s (in reverse alphabetical
order?), and then I have some legitimate c/a/ds (sys/src/games/mp3enc)
on account of I haven't pulled in awhile. But the initial
additions/deletions are disjoint sets as far as I can tell - why don't
I see deletions followed by additions for the same files?
-sqweek