On Nov 28, 2007 1:21 PM, Russ Cox <[EMAIL PROTECTED]> 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
