ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <>
Subject Re: tar task problems
Date Thu, 25 Jan 2007 09:05:16 GMT

On 24.01.2007, at 20:18, Stefan Bodewig wrote:
> On Wed, 24 Jan 2007, Torsten Curdt <> wrote:
>> AFAIU the only way of modifying TGZs and retain meta date like
>> permissions and ownerships is to nest the TAR with the UNTAR (ZIP/
>> UNZIP) process (as TarResource object getting passed through).
> You are correct.  <zip> does have an update attribute, but tar
> doesn't.

Actually I would also need the mapping. So even updating would not  
even be enough. Basically I want to move resource from inside a tgz


into a new tgz as


without going through the filesystem as that will strip of meta  
information like permissions, ownerships and links.

>> While this seems to work fine for ZIP, the TAR task bails out with
>>  "Problem creating TAR: request to write '0' bytes exceeds size in
>> header of '-1' bytes for entry ''"
> Ouch.  It might be due to your specific tar archive, I think we do
> have a unit test that re-tars a tar, but I could be wrong.

There is the TarRoundTripTest ...but that just that creates a tar and  
then reads from it. Similar but not the same.

> I'm not aware of any prior report of this bug, but then again a lot of
> issues have been opened without me following close enough.

I had another look but also could not find a matching bug yet.

> If you can provide a simple test tar.gz for us, writing an AntUnit
> test would be trivial.

OK ...I have opened a bug for it

Please let me know if you can reproduce it.

>> Also I am wondering why mappers are not supported.
>>   <target name="tgz">
>>       <tar destfile="${build}/release.tgz">
>>           <fileset dir="src/site"/>
>>           <tarfileset src="src/release.tgz"/>
>>           <mapper type="..."/>
>>       </tar>
>>   </target>
>> By design or would a contribution be welcome? :)
> Not by design, just because nobody added it.
> If you wanted to contribute anything, a MappedResourceCollection like
> <mappedresources>
>   <tarfileset src="src/release.tgz"/>
>   <mapper type="..."/>
> </mappedresources>
> might be worth a try as it would add mapping functionality to any task
> accepting resource collections.

That would be nice. but...

> This approach wouldn't work in your case, though, since we'd lose
> permission information (the task wouldn't know there is a tarfileset
> decorated by the mapped collection).

...that's what I feared. Because the mapper creates a new Resource  
object I assume? On the other hand the Resource object is Cloneable.  
Shouldn't it be possible to clone the orignal object an then just map  
the name? That should in theory keep the original meta data as long  
as the TarResource supports cloning as well. Or am I missing here  


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message