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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
