On 24.01.2007, at 20:18, Stefan Bodewig wrote:
On Wed, 24 Jan 2007, Torsten Curdt <[EMAIL PROTECTED]> 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
/project/bla/blub
into a new tgz as
/opt/some/project/bla/blub
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
http://issues.apache.org/bugzilla/show_bug.cgi?id=41458
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
something?
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
