Re: tar extract changed since netbsd-8? (extracting sets over running system)

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Wed, Nov 13, 2019 at 10:34:51PM -0000, Christos Zoulas wrote:
> In article <20191113222728.GA79690%bec.de@localhost>,
> Joerg Sonnenberger  <joerg%bec.de@localhost> wrote:
> >On Wed, Nov 13, 2019 at 10:24:21PM -0000, Christos Zoulas wrote:
> >> I don't want processes to die of fail to start because I am extracting
> >> a tar file and I happen to be overwriting libc. It just does not
> >> need to happen and it did not happen before.
> >
> >This argument is plainly false. It was never safe to do, especially when
> >a library changes in incompatible ways. /bin/ls depending on a new
> >system call and the extract hasn't reached /lib/libc.so.12 yet? Boom.
> 
> It is always safe to do when building from the same sources. It is
> also safe to do when using a new system call and using a new kernel
> (the new kernel has it, the new libc can immediately use it). I
> extract base.tgz all the time on live systems and never had any
> issues.
> 
> The "incompatible ways" argument is not my point. The point is the
> lack of atomicity, which we had before and now we lost.  It is not
> safe anymore to extract libc on a running system because any new
> processes trying to start while libc is incomplete/missing will die.
> At least it does not kill the current process because it unlinks... :-)

No, it was never atomic. Please read again what I wrote. /bin/ls and
/lib/libc.so.12 are not updated at the same time. That's the very
definition of non-atomic. In theory we could do a topological sort of
all sets to ensure that the shared libraries are placed first, but we
don't. So please stop pretending that any life update that involves an
API change of shared libraries is safe. It is not.

Anyway, the point is mood. I've reverted MKBSDTAR to no, so that
everyone can be happy.

Joerg