David Brownlee <a...@absd.org> writes:

> On Thu, 14 Nov 2019 at 21:05, Christos Zoulas <chris...@astron.com> wrote:
>> 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

<aol>Me too.</>

My sense of the list is that

  most people want unpacking sets over a system to work as well as it
  used to work

  some people really want a tar that handles newer formats, and probably
  everything thinks this would be good

  some concern has been expresseed over performance, but more people
  have expressed the notion that things working correctly (which does
  not have a universal definition) is more important.

so Christos's proposal seems to steer very well to this rough consensus.

> Thanks for working on this!


Reply via email to