You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Roland Ramthun <ad...@yacy-forum.de> on 2005/07/28 12:17:02 UTC
Bug in tar-section
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.
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.
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.
Thank you.
Roland Ramthun
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Bug in tar-section
Posted by Roland Ramthun <ad...@yacy-forum.de>.
Peter Reilly schrieb:
> From the ant manual:
> "Early versions of tar did not support path lengths greater than 100
> characters. Modern versions of tar do so, but in incompatible ways. The
> behaviour of the tar task when it encounters such paths is controlled by
> the /longfile/ attribute. If the longfile attribute is set to |fail|,
> any long paths will cause the tar task to fail. If the longfile
> attribute is set to |truncate|, any long paths will be truncated to the
> 100 character maximum length prior to adding to the archive. If the
> value of the longfile attribute is set to |omit| then files containing
> long paths will be omitted from the archive. Either option ensures that
> the archive can be untarred by any compliant version of tar. If the loss
> of path or file information is not acceptable, and it rarely is,
> longfile may be set to the value |gnu|. The tar task will then produce a
> GNU tar file which can have arbitrary length paths. Note however, that
> the resulting archive will only be able to be untarred with GNU tar. The
> default for the longfile attribute is |warn| which behaves just like the
> gnu option except that it produces a warning for each file path
> encountered that does not match the limit."
>
> The tar page that Steve pointed out shows that there is a new posix tar
> format that will be used
> by gnu tar in the future - ant will probally support that then.
Ok, that answers my question.
Thank you.
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Bug in tar-section
Posted by Peter Reilly <pe...@apache.org>.
From the ant manual:
"Early versions of tar did not support path lengths greater than 100
characters. Modern versions of tar do so, but in incompatible ways. The
behaviour of the tar task when it encounters such paths is controlled by
the /longfile/ attribute. If the longfile attribute is set to |fail|,
any long paths will cause the tar task to fail. If the longfile
attribute is set to |truncate|, any long paths will be truncated to the
100 character maximum length prior to adding to the archive. If the
value of the longfile attribute is set to |omit| then files containing
long paths will be omitted from the archive. Either option ensures that
the archive can be untarred by any compliant version of tar. If the loss
of path or file information is not acceptable, and it rarely is,
longfile may be set to the value |gnu|. The tar task will then produce a
GNU tar file which can have arbitrary length paths. Note however, that
the resulting archive will only be able to be untarred with GNU tar. The
default for the longfile attribute is |warn| which behaves just like the
gnu option except that it produces a warning for each file path
encountered that does not match the limit."
The tar page that Steve pointed out shows that there is a new posix tar
format that will be used
by gnu tar in the future - ant will probally support that then.
Peter
Roland Ramthun wrote:
>Steve Loughran wrote:
>
>
>
>>>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.
>>
>>
>
>So there are different versions of the tar specifications?!
>
>But then it is an rather easy question: Which one does Ant use?
>Then you may look if it is implemented correctly or not.
>If Ant uses a version which doesn't allow more than 99 chars it's ok,
>but then it shouldn't build files with more, which lead to irritations
>in programs which follow the standard...
>And don't forget we had problems with a linux program, too.
>
>It is not interesting how the standard tar-program builds its tarballs.
>Either it works as defined by the standard or it does not.
>Then it has a bug.
>
>Regards
>Roland
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>For additional commands, e-mail: dev-help@ant.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Bug in tar-section
Posted by Roland Ramthun <ad...@yacy-forum.de>.
Steve Loughran wrote:
>> 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.
So there are different versions of the tar specifications?!
But then it is an rather easy question: Which one does Ant use?
Then you may look if it is implemented correctly or not.
If Ant uses a version which doesn't allow more than 99 chars it's ok,
but then it shouldn't build files with more, which lead to irritations
in programs which follow the standard...
And don't forget we had problems with a linux program, too.
It is not interesting how the standard tar-program builds its tarballs.
Either it works as defined by the standard or it does not.
Then it has a bug.
Regards
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Bug in tar-section
Posted by Steve Loughran <st...@apache.org>.
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