Re: [9fans] Plan 9 wiping itself?

["Russ Cox" <rsc@swtch.com>]

>  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.

Actually the problem was that updatedb *wasn't* aborting.
The network connection got lost halfway, so a lot of files "disappeared"
so updatedb thought they had been deleted.  And then it found
them the next time it ran.  I just submitted a fix so that it will
notice network errors and stop before inferring file deletions.
This won't happen again (and if it does, pull is smarter anyway).

>  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?

The log occasionally gets compressed (really, canonicalized)
to remove redundant events.  When that happens, the canonical
replacement form is an "a" event for every file on the system 
followed by a "d" for every file that existed in the past and got deleted.
Putting the "d" events in reverse alphabetical order deletes files
before their parent directories.  The two sets are disjoint because
redundant event sequences have been collapsed into a single "a" or "d".

Geoff compressed the log yesterday so that the big
"delete /sys/src and then recreate it" sequence would go away.
And then after compressing the log a few more entries got added.

There's not a lot of difference between "a" and "c".  If the log says "a"
but the file already exists (and was created by replica) then it's
treated as a "c".  The "a" events you saw were really the "c" events
that had happened before the log got compressed and that you
hadn't yet pulled.  Probably "c" should go away.

Russ