In article <CAHKF-At+gDp3kqR-Joi2H7fdU3ZeugUg9SKpPbH8Q-wf=pp...@mail.gmail.com>, matthew sporleder <msporle...@gmail.com> wrote: >On Tue, Nov 12, 2019 at 8:51 AM Joerg Sonnenberger <jo...@bec.de> wrote: >> >> On Tue, Nov 12, 2019 at 08:25:46AM -0500, Greg Troxel wrote: >> > David Brownlee <a...@absd.org> writes: >> > >> > > On Tue, 12 Nov 2019 at 11:33, JaromÃr DoleÄek ><jaromir.dole...@gmail.com> wrote: >> > >> >> > >> Le mar. 12 nov. 2019 à 12:05, Martin Husemann ><mar...@duskware.de> 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