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

Thanks for working on this!


Reply via email to