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

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

In article <CAHKF-At+gDp3kqR-Joi2H7fdU3ZeugUg9SKpPbH8Q-wf=PPUfA%mail.gmail.com@localhost>,
matthew sporleder  <msporleder%gmail.com@localhost> wrote:
>On Tue, Nov 12, 2019 at 8:51 AM Joerg Sonnenberger <joerg%bec.de@localhost> wrote:
>>
>> On Tue, Nov 12, 2019 at 08:25:46AM -0500, Greg Troxel wrote:
>> > David Brownlee <abs%absd.org@localhost> writes:
>> >
>> > > On Tue, 12 Nov 2019 at 11:33, Jaromír DoleÄ?ek
><jaromir.dolecek%gmail.com@localhost> wrote:
>> > >>
>> > >> Le mar. 12 nov. 2019 Ã  12:05, Martin Husemann
><martin%duskware.de@localhost> a écrit :
>> > >>>
>> > >>> Not seen this locally, but that would be the switch to
>bsd/libarchive tar.
>> > >>> Maybe it does not unlink files before extraction and replaces
>them in-space?
>> > >>>
>> > >>> I do the same kind of updates, but usually on a very quiet system.
>> > >>>
>> > >>> The crashes you see are from other running processes? Joerg would likely
>> > >>> say: "don't do that" ;-)
>> > >>>
>> > >>
>> > >> I thought we do unlink by default, I think I remember a commit to
>that effect in past. The unlink is very useful default behaviour of GNU
>tar. In-place overwrite is very rarely the wanted behaviour.
>> > >
>> > > Aha thanks!
>> > >
>> > > I would argue the switch to unlink no longer being the default is a
>> > > regression. If its mandated by standards or we're the only outlier
>> > > then it probably makes sense to switch, but otherwise its sprinkling
>> > > occasional non deterministic breakage across a bunch of scripts which
>> > > previously ran fine on NetBSD.
>>
>> It does not force an unlink first, but will unlink if there is a
>> conflict. So the question would be why open(2) with O_CREAT|O_EXCL
>> doesn't fail.
>>
>> > I'm not quite clear on 'unlink by default', but it seems to me the
>> > replacement files should be written to a temporary name and then
>> > renamed() into place so the file is either the old version or the new
>> > version.
>>
>> That would dramatically increase the time it takes for an untar for
>> little to no gain.

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:

    https://nxr.netbsd.org/xref/src/bin/pax/file_subs.c#238

christos