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

[christos%astron.com@localhost (Christos Zoulas)]

In article <20191113215801.GA113409%bec.de@localhost>,
Joerg Sonnenberger  <joerg%bec.de@localhost> wrote:
>On Wed, Nov 13, 2019 at 07:29:59PM -0000, Christos Zoulas wrote:
>> Yes, but open(O_EXCL) does not protect you against mmapped segments
>> (which has the potential to kill running processes that use shared
>> libraries/jar/other mapped files) or crashing in the middle of
>> writing a file and leaving stuff 1/2 written. For me safety trumps
>> speed (after all we don't mount our filesystems async :-), so I
>> would prefer that the default is slow and safe as opposed to fast
>> and unsafe, like the old pax/tar did:
>
>O_EXCL|O_CREAT does not allow overwriting mmapped text segments. Always
>writing new files and renaming doesn't make live updates safe either.
>E.g. consider the case of a new symbol being updates to a shared
>library.

jars are not text segments. NFS can't know. Libarchive tries
O_EXCL|O_CREAT, fails on existing files, unlinks and tries again.
This creates a race condition when the file does not exist or the
file is incomplete. All this stuff is simpler using rename(2).

Yes, it can use double the disk space. Disks are big; remove before
hand if you think you don't have space and re-extract.

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. With tar/libarchive
I don't even have an option to use rename, so I wrote one:

https://www.netbsd.org:~christos/libarchive-atomic.diff

And this is what I will be using locally because I don't like accidents :-)

christos