From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <775b8d190604180244o71d59d15lb1596481daed3ba2@mail.gmail.com>
Date: Tue, 18 Apr 2006 19:44:47 +1000
From: "Bruce Ellis" <bruce.ellis@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: [9fans] replica's _* files
In-Reply-To: <077d0d5f265520782ac4ebef832f7cea@swtch.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <444402F1.9040301@gmail.com>
	<077d0d5f265520782ac4ebef832f7cea@swtch.com>
Topicbox-Message-UUID: 3a392452-ead1-11e9-9d60-3106f5b1d025

unfortunately this method does'nt solve the problem.

you have to reboot after a replica/pull ... unless
you don't indeed to do it again.

simple exmple ... your rio, which has been running
for weeks/months becomes _rio ... and the next
update overwrites your _rio.

correct me if i'm wrong.

i'd rather them be rename in _i++.

brucee

On 4/18/06, Russ Cox <rsc@swtch.com> wrote:
> When a new binary (e.g., /386/bin/rio) gets pulled,
> the old one, which you might still be running,
> is renamed to the _ version so that it keeps working.
> If you remove _rio while someone is still executing
> it and then they try to demand load a page from the binary,
> the running rio will die.
>
> After rebooting the machine so that you're running the
> new binaries, then it's safe to remove _*.
>
> There is no fossil console command to zero unused fossil blocks.
> The source is in /sys/src/cmd/fossil if you'd like to add one.
>
> Russ
>
>