bug-automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#19616: [Bug-tar] dist tarball contains hardlinks


From: Pavel Raiskup
Subject: bug#19616: [Bug-tar] dist tarball contains hardlinks
Date: Wed, 21 Jan 2015 14:35:26 +0100
User-agent: KMail/4.14.3 (Linux/3.17.8-300.fc21.x86_64; KDE/4.14.3; x86_64; ; )

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]