From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <140e7ec30711272343x6f017db3v90053f21cb161884@mail.gmail.com> Date: Wed, 28 Nov 2007 16:43:10 +0900 From: sqweek To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] Plan 9 wiping itself? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <10b109140711240944q1f49e04ftfc7687a47ee72846@mail.gmail.com> <21D705DE-C4AA-43C0-A0CE-640827386D6D@mac.com> <5d375e920711241043i4a838fcm7fb52c104b05a94d@mail.gmail.com> Topicbox-Message-UUID: 0d2ac798-ead3-11e9-9d60-3106f5b1d025 On Nov 28, 2007 1:21 PM, Russ Cox 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 > 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