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. > > Joerg
If you try the same thing on FreeBSD does the same error happen?
