On Thu, 14 Nov 2019 at 21:05, Christos Zoulas <chris...@astron.com> wrote: > > In article <2c05e1ed-8410-fa0f-d786-06ee6e1c4...@marples.name>, > Roy Marples <r...@marples.name> wrote: > >On 14/11/2019 05:47, Martin Husemann wrote: > >> On Thu, Nov 14, 2019 at 03:53:02PM +1100, matthew green wrote: > >>> i'm not happy about this change. i wish that bsdtar was > >>> fixed to not be unfriendly, because it mostly is a better > >>> implementation. just these edge cases are rather .. > >>> problematic yet these issues are being ignored or > >>> rejected as being irrelevant. > >> > >> Me neither, especially as we now effectively have different command line > >> args passed from sysinst to tar depending on the tar invocation (and this > >> is all hard coded). I'll have to make it a define in sysinst depending > >> on the seleted tar variant :-/. > > > >Just for the record, I don't really care about different cmd line args, > >symlinks and security involved. > > > >My expectation is that a modern NetBSD tar can extract a modern tar > >archive from other sources. > > > >If it cannot do this we have failed. > > So I am trying to find some time to pursue the two issues I have > with upstream and understand if they will accept the following two > changes (or versions thereof): > > The first issue is that I prefer to have tar respect existing > symlinks (ones that it did not create by default -- without having > to specify extra flags) since to do this (in my opinion) does not > pose a security risk. Yes my implementation is Q+D, but it works. > > https://www.netbsd.org/~christos/track-symlinks.diff > > The second issue is that the way libarchive-tar overwrites existing > files is by removing them first, and writing them directly to the > final destination pathname. This creates a significant amount of > time where the file is either not available or not completely > written. Imagine trying to replace shared libraries or programs > frequently used. Pax-as-tar wrote the file to a temporary one first > and used rename(2) to atomically replace it. I've written a patch > to do the same for libarchive-tar: > > https://www.netbsd.org/~christos/libarchive-atomic.diff > > With those two patches we can put libarchive as tar back and we don't > need to make any other changes since behavioraly the old pax-as-tar > and libarchive-tar behave the same for those two cases that bothered us. > > I am inclined to just commit them and flip the default again.
I could see an argument for having an option to turn off the extract-to-temp-and-rename behaviour (not that I'd use it), but I'd be very happy to see both above changes in as defaults and us back onto libarchive-tar Thanks for working on this! David
