GNU bug report logs - #19616
dist tarball contains hardlinks

Previous Next

Full log

Message #44 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dimitrios Apostolou <jimis <at> gmx.net>
To: Pavel Raiskup <praiskup <at> redhat.com>
Cc: Joerg Schilling <Joerg.Schilling <at> fokus.fraunhofer.de>, eggert <at> cs.ucla.edu,
 bug-automake <at> gnu.org, bug-tar <at> gnu.org
Subject: Re: [Bug-tar] dist tarball contains hardlinks
Date: Fri, 13 Mar 2015 16:33:37 +0100 (CET)

On Tue, 27 Jan 2015, Pavel Raiskup wrote:
> On Monday 26 of January 2015 12:12:09 Dimitrios Apostolou wrote:
>> On Fri, 23 Jan 2015, Pavel Raiskup wrote:
>>
>>> On Friday 23 of January 2015 15:45:57 Dimitrios Apostolou wrote:
>>>> Thank you Joerg. If so then it is an issue that must be fixed in
>>>> automake, which is the reason I cross-posted to both projects, because I
>>>> am not sure which one should be changed!
>>>
>>> What solution you exactly propose?  Note that 'h' tar option is used for
>>
>> Maybe adding --hard-dereference? That's how I worked around the issue at
>> least.
>
> From the automake POV, this is not standardized option (could be used only
> for GNU tar if present though).

You are right. I /thought/ I had resolved the problem by exporting 
TAR_OPTIONS=--hard-dereference. Unfortunately the problem persists, "make 
dist" fails on RHEL4 for example because tar sees this unrecognized 
option.

>
>>> dist from Y1996 commit [1] and its removal is unlikely.  It is quite
>>> portable and it, as the "default", works for many packages.
>>
>> It has been there since 1996, so the legacy behaviour of tar has been
>> battle tested. However the new behaviour (hard links in place of
>> symlinks) is probably only tested for a couple of years,
>
> Truth.  The new behavior is in tar from 1.24.  However, if we fixed this
> in tar, GNU tar v1.24 to v1.28 still would not able to mimic the old
> behavior.

I believe my only choice at this point is to forbid "make dist" if tar is 
detected to be old (less than 1.29), and keep doing --hard-dereference. I 
open to new ideas though. :-)

>>
>> Using "tar-ustar" format for distribution you are supposed to raise some
>> of the limits of the "v7" tar format but retain portability. Indeed, the
>> length limit for regular files used to be 256 characters [2], and since
>> all symlinks were stored as files that was universal. Now that symlinks
>> are stored as hard links, the limit is 100 characters for those, thus
>> I've hit this problem.
>>
>> [2] http://www.gnu.org/software/tar/manual/html_section/tar_68.html
>
> Yes, thanks - I see now.  In ustar link name must fit into 100 characters
> and the file path can be theoretically max 256 (if it is splittable
> correctly into prefix/name).
>
> You seem to have *directory* in some distribution sensitive variable,
> like:
>
>  # Directory contains 'file' and 'link -> file'.
>  EXTRA_DIST = directory
>
> .. Because if you had:
>
>  EXTRA_DIST = directory/file directory/link
>
> then automake (via 'cp -p') would follow the link for you.  In case of
> directories (before the actual 'tar ch' happens) automake copies the
> directory recursively by 'cp -fpR' [2] into temporary directory.

I don't think this solution is worth the trouble in my case, since the 
directory included has a deep and complex structure (hence some files 
surpass 100 characters).


Thanks,
Dimitris


>
> Could we add '-L' option to this cp call (dist target is not supposed to
> be portable to everywhere and -L is POSIX)?  Obviously, the archive bloat
> is not something automake tries to avoid.
>
> Anyway, I don't feel the handling of symbolic-links this way is correct.
> Don't we wan't to use something like $LN_S [autoconf manual] in such
> cases?
>
> [1] https://lists.gnu.org/archive/html/bug-tar/2011-01/msg00000.html
> [2] http://git.savannah.gnu.org/cgit/automake.git/tree/lib/am/distdir.am?id=6357a630dc#n193
>
> Pavel
>
>

Previous Next

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