This is fixed now on Tar.jl master (and making its way to Julia master). I haven’t made a release of Tar with this yet because this is a pretty niche “feature” and I prefer to let things simmer before cutting a release (in case there’s issues I didn’t catch). As is somehow always the case, the change was more involved than expected, but I think that’s because I always end up expanding the test coverage when I fix things or add features. I considered just making this an error since it’s such an odd thing for a tarball to do, but I explained my reasoning for supporting it in the commit message:
This is a weird construction: an entry for a file followed by a hardlink with that file as its target and with the same path. The hardlink copies the content of its target and creates a file with the “new” path and mode, which happens in this case to be the same path as the original file. The effect of this construction is to change the permissions of a previous file entry. We could diallow this since it’s odd, but based on the bug report it is something
tarcan generate and the other tarball reading methods liketree_hashandrewritealready just work because the logic is simply to copy the contents of an existing node with a new path and mode and for a sane tree data structure, you can just overwrite an arbitrary node. The file system is wonkier and the change in logic here is merely to ensure that the old file isn’t deleted too early.