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
