Re: tar task problems

Thread: Re: tar task problems

Search this list only Search all lists
Re: tar task problems
	2007-01-24 13:18:09
On Wed, 24 Jan 2007, Torsten Curdt apache.org> 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. does have an update attribute, but tar doesn't. > 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. 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. If you can provide a simple test tar.gz for us, writing an AntUnit test would be trivial. > Also I am wondering why mappers are not supported. > > > > > > > > > > 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 might be worth a try as it would add mapping functionality to any task accepting resource collections. 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). Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribeant.apache.org For additional commands, e-mail: dev-helpant.apache.org
Re: tar task problems
	2007-01-25 03:05:16
On 24.01.2007, at 20:18, Stefan Bodewig wrote: > On Wed, 24 Jan 2007, Torsten Curdt apache.org> 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. 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. >> >> >> >> >> >> >> >> >> >> 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 > > > > > > > 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: dev-unsubscribeant.apache.org For additional commands, e-mail: dev-helpant.apache.org