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. Best, christos