Re: CVS commit: src/share/mk

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

In article <2c05e1ed-8410-fa0f-d786-06ee6e1c4a95%marples.name@localhost>,
Roy Marples  <roy%marples.name@localhost> 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.

Best,

christos