Re: Unexpected behaviour when creating a tarball with -h: symlinks are replaced with hardlinks

[Mirko Vogt]

Since I didn't get any replies via mail, but only see them in the
mailman web frontend, I have to reply to my own mail instead of to
specific responses:


On 8/14/20 4:29 PM, Mirko Vogt wrote:> However what I'm experiencing is
- while -h indeed does not preserve the
> symlinks - it replaces them with hard links instead of actually
> de-referencing them and including the original file.
> 
> This in particular is an issue, if you want to create a tarball for a
> filesystem which doesn't support any of such link types - e.g. FAT.

I found this very commit from 2010 introducing this behaviour:



http://git.savannah.gnu.org/cgit/tar.git/commit/?id=37ddfb0b7eb41cc3f58bce686d389b1e965e9ccf



and a thread about it from late 2011 on this ML:



https://lists.gnu.org/archive/html/bug-tar/2011-11/msg00024.html



and from there figured, that for my use-case I'm supposed to call tar
with "-h --hard-dereference" - which does the job indeed.



While I'm not sure I'm liking or disliking the "new" "-h"-behaviour in
general, multiple copies of the same file being handled as the same
(hardlinking them at archive creation) definitely saves space for the
final tarball.



However given what the man page says:



       -h, --dereference



              Follow symlinks; archive and dump the files they point to.



it's not just misleading, but - please correct me if I'm
misreading/overlooking sth. - plainly wrong.

Basically they're converted to hardlinks.



And that results in real-world issues, when extracting them on
filesystems not supporting hardlinks - despite having called it with
"-h" after having read and followed the man page.



So from my point of view I'd at least see some clarification for "-h" in
the man / help page and maybe even a hint to "--hard-dereference" if the
use-case is to avoid links at all (like in my case).

  mirko