GNU bug report logs - #19616
dist tarball contains hardlinks

Previous Next

Full log

View this message in rfc822 format

From: Pavel Raiskup <praiskup <at> redhat.com>
To: bug-tar <at> gnu.org
Cc: jimis <at> gmx.net, 19616 <at> debbugs.gnu.org
Subject: bug#19616: [Bug-tar] dist tarball contains hardlinks
Date: Wed, 21 Jan 2015 14:35:26 +0100

On Friday 16 of January 2015 16:43:20 Dimitrios Apostolou wrote:
> (Cross posting to both bug-automake and bug-tar as I can see both projects
> being affected.)
> (Please keep me CC'd as I'm not subscribed.)
>
> Hello,
>
> this bug report is because of the following messages when extracting a
> source tarball generated with "make dist". You can read the full bug
> report at https://dev.cfengine.com/issues/6925.
>
> # tar -xzf core/cfengine-3.7.0a1.5ffcc54.tar.gz
> tar: cfengine-3.7.0a1.5ffcc54/tests/acceptance/17_users/unsafe/10_modify_user_with_same_password.cf: Cannot hard link to `cfengine-3.7.0a1.5ffcc54/tests/acceptance/17_users/unsafe/20_modify_user_with_same_password_hpux_tru': No such file or directory
> [...]
>
> Regading automake, it implements "make dist" using "tar -chf" where -h
> stands for --dereference, i.e. it dereferences all symlinks. I believe
> I've read that it is for portability, because symlinks are handled in a
> variety of manners in different tar implementations. However as seen
> above, what actually happens is that GNU tar stores the symlinks as
> hardlinks. Because the total path length of the hardlinks is more than 100
> characters, they get truncated due to "ustar" format limitations (ustar
> format is chosen using the "tar-ustar" automake option).

When using automake, try to use:

  AM_INIT_AUTOMAKE([filename-length-max=99])

That breaks 'make dist' as you would expect.  Maybe this could be done by
default for certain archive formats (or make dist could be silenced a
little to see tar's warnings).

> Please notice that removing "-h" fixes the problem. Symlinks are stored
> properly as their length is much smaller than 100 chars (because they are
> relative symlinks).

Not much - when 'tar chf -' (and in your example) the symlinks are
probably just (with a bit of luck) a bit smaller than not archived files.

> Another workaround (the one I chose to use) is to pass the
> --hard-dereference to GNU tar in order to store the content of the files
> itself, avoiding all kind of links, and maintaining best portability. So
> I've added the following lines in my Makefile.am:

Also, when fighting with 'tar chf -', you may AC_SUBST([am__tar]) to whatever
you want.  This would replace what is automatically detected by m4/tar.m4.

Pavel

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.