-h seems to store symlinks as hardlinks

[Christoph Viethen]

Ubuntu Release 11.04

tar -chf test.tar someDirectory

will generate a hardlink for each file that contained a *symbolic* link in its path in the original directory.

Only writing

tar --hard-dereference -chf test.tar someDirectory

will prevent this from happening and store all files, also the ones reached through symbolic links, as plain files, removing all indications that there once were links.

To me, this is a bug, since
a) the option -h alone should cause all symbolic links to disappear, with the files originally reached through a symbolic link being dumped as plain files and
b) I don't see any good reason in creating hardlinks (possibly later on as well, after extracting the file again) for symlinks, effectively changing one kind of link into the other.

Expected behaviour to me would be that of tar 1.23, which stores symbolically linked files as plain files, just like the documentation (for both tar versions) says:

"-h follow symlinks; archive and dump the files they point to"

To me, this bug is a real showstopper because it causes related trouble in a project I'm working in. A rapid resolution would be extremely nice.

[Daniel Manrique (roadmr)]

I tested this with tar 1.25 under Ubuntu 11.10.

Steps to reproduce:
mkdir /tmp/tar-link-test
dd if=/dev/urandom of=/tmp/tar-link-test/testfile count=2
ln -s /tmp/tar-link-test/testfile /tmp/tar-link-test/testfile.link
tar -chf /tmp/test-tar.tar /tmp/tar-link-test
tar -tvf /tmp/test-tar.tar

Expected output:

drwxrwxr-x roadmr/roadmr 0 2011-11-25 11:22 tmp/tar-link-test/
-rw-rw-r-- roadmr/roadmr 1024 2011-11-25 11:22 tmp/tar-link-test/testfile
-rw-rw-r-- roadmr/roadmr 1024 2011-11-25 11:22 tmp/tar-link-test/testfile.link <- this being an actual file

Actual output:

drwxrwxr-x roadmr/roadmr 0 2011-11-25 11:22 tmp/tar-link-test/
-rw-rw-r-- roadmr/roadmr 1024 2011-11-25 11:22 tmp/tar-link-test/testfile
hrw-rw-r-- roadmr/roadmr 0 2011-11-25 11:22 tmp/tar-link-test/testfile.link link to tmp/tar-link-test/testfile

[Daniel Manrique (roadmr)]

This behavior seems to have changed in GNU tar 1.24. See this mailing list thread:

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

As per the thread, the commit that added the new behavior is:

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

So it appears this new behavior is "by design" and the intended way to get the new behavior is to, as you mention, use --hard-dereference.

[Daniel Manrique (roadmr)]

Set bug to confirmed pending the original reporter's review of the linked information from upstream. Importance is Low as it has an easy workaround (give --hard-dereference).