ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@apache.org>
Subject Re: Bug in tar-section
Date Thu, 28 Jul 2005 12:32:15 GMT
Roland Ramthun wrote:
> Hello,
> we are using Ant to build the software we provide.
> We have a section in our buildfile, which tars and gzips the program at
> the end of the build process.
> 
> Some days ago an users complained about problems unpacking this archive
> using WinRAR.
> Another user had problems under Linux (program unknown), too.
> 
> Instead of 
> "yacy_v0.391_20050726_434\classes\de\anomic\kelondro\kelondroMScoreCluster$komplexScoreIterator.class"
> they got
> "yacy_v0.391_20050726_434\classes\de\anomic\kelondro\kelondroMScoreCluster$komplexScoreIterator.class0000644".
> 
> We thought this was an error on WinRARs side, so an user contacted the
> author Eugene Roshal.
> 
> He gave the following answer:
> ---
> Hello,
> 
> 
>>so you are able to reproduce the problem
> 
> 
> Yes.
> 
> 
>>and you can confirm that this is a bug in WinRAR?
> 
> 
> It is a buggy archive, which could be processed better by WinRAR,
> but I would not call it WinRAR bug. We did not use GNU tar source code
> in WinRAR, but implemented tar support from a scratch basing on
> TAR format specifications from tar.info. So in some situations
> WinRAR can conform to these specifications better than original TAR.

I dont want to get into recriminations here, and while I celebrate tools 
that are strict about what they generate,
all downstream things have to be forgiving about what they process. And 
you need lots of test files generated by different tools.

> tar.info clearly states that name field must be null-terminated.
> So if name length is equal to size of this field (100) as in case of
> that
> yacy_v0.391_20050726_434\classes\de\anomic\kelondro\kelondroMScoreCluster$komplexScoreIterator.class,
> 
> in my opinion the correct behavior for TAR archiver would be to place
> 99 characters to name field and then use either "ustar" or "././@LongLink"
> methods to store the full name. Storing 100 characters in the name field
> does not match specifications and such archive cannot be considered as
> correct, even though it is supported by tar and now by WinRAR

Therein lines the problem. If tar itself can create files of this type, 
then everything downstream has to handle it. Indeed, I suspect the C 
routine strncpy() was used in tar at has the exact semantics of "add a 
zero to the end, except when the full length is used up".


> 
> Besides, I placed a new build of WinRAR 3.50 beta 7 to www.rarlab.com.
> <http://www.rarlab.com.>
> If you wish, you can download it and check if it handles this archive well.
> 
> Eugene
> ---
> 
> Please fix this problem.
> If you utilise code of another GNU project for the tar section of ant,
> please forward this email to them or give me their contact address and I
> will do so.

I'm not sure if we want to fix it. This is not me being selfish, it is 
this: by limiting the length of a classic tar to 99 chars over 100, just 
to support one program that followed the tar spec more strictly than the 
common tar implementations, then we may more builds that used to work 
before.

At the same time, the gu tar spec on the v7 format  does say "The 
maximum length of a file name is limited to 99 characters." :
http://www.gnu.org/software/tar/manual/html_chapter/tar_8.html#SEC120

so we may want to warn more early.

Returning to your build file, Ant only generates gnu files when you 
request them:
longfile="gnu"

There are still a lot of legacy tar systems out there, and so we dont 
want to silently generate long filename tars without control. Once you 
flip that switch, it is up to you to deal with the support calls related 
to "tar doesnt work right" that follow...

-steve

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message