Andrew Myers wrote:
Hi Oliver,
Thanks for the feedback.
I suspect the reason it is returning -1 is because I am not calling the
setSize method on the ZipEntry when I create it. There's a few other
setters I think I need to call that I'm not, such as
setCompressedSize
setMethod
and probably some others
If anyone can give me a hand with this I would very much appreciate a nudge
in the right direction.
I tried setting the ZipEntry size with "zEntry.setSize(file.length());"
in processFile() but this doesn't make a difference - when I come to
list the files getSize() and getCompressedSize() still return -1.
I had a feeling this might be a bug in ZipOutputStream/ZipInputStream,
so I took a look in the code there for the putNextEntry() and
closeEntry() methods. It looks like when we are just storing the data
(no compression) we write the sizes first. When we compress the data we
store the sizes after the data is written, so we know the compressed
size, in a different location in the file. However, looking into
ZipInputStream.getNextEntry() we only seem to read the size in the case
where the data is stored uncompressed, and don't read it at all in the
case where the data is compressed. This leaves the sizes (and the crc)
as the default values, which are -1. I've discovered we also display the
entry size as -1 when the jar is created by the RI. So it appears the
way we write the ZipEntry is correct, but the way we read it is broken,
which explains why the RI can read the ZipEntry size correctly when the
jar is created by our tool. I'll see if I can figure out the right thing
to do in getNextEntry() to read the sizes from the correct location.
So in the default
I'll fix the other issue with the buffering - that one I do know how to do
:-)
Cool - thanks!
Regards,
Oliver
Andrew.
2009/7/30 Oliver Deakin <oliver.dea...@googlemail.com>
Hi Andrew,
I've applied the patch from HARMONY-6255 now and it's looking good. The
only slightly strange thing I've noticed is that when I create an archive
with a command line something like:
jar -cf foo.jar HelloWorld.class
and then list it's contents with "jar -tvf foo.jar", I get -1 as the size
of the ZipEntry for some reason:
target\hdk\jdk\bin\jar -tf foo.jar
-1 Thu Jul 30 09:46:38 GMT+01:00 2009 HelloWorld.class
However, if I run with jar from the RI it displays the ZipEntry size
correctly:
717 Thu Jul 30 09:46:38 BST 2009 HelloWorld.class
In the listJar() method we use ze.getSize() to get the ZipEntry size to
display, which works for jars not packed by our own jar tool. Any idea why
it wouldn't work for jars packed by our jar?
Just a quick note on the processFile() method - I notice that it reads the
entire file to be packed into a buffer and then writes it all out again in
one go. This is ok for small files, but I could see a problem when we get to
packing files which are very large - do you think it would be better to have
a predefined buffer size here (say 1000 bytes) and read/write in a loop, one
chunk at a time? We can use the return value from FileInputStream.read() to
tell us how many bytes have been read and then pass this value to
ZipOutputStream.write().
Regards,
Oliver
Oliver Deakin wrote:
No problem Andrew :)
Regards,
Oliver
Andrew Myers wrote:
I might have worked this out myself. Sorry I'm so slow with this - but I
am
progressing. I will have something to show tomorrow I hope.
2009/6/16 Oliver Deakin <oliver.dea...@googlemail.com>
Hi Andrew,
Great to hear you've got back into the jar tool! I think the best thing
is
to direct your questions to the dev@ list, however simple or complex
they
may be. Everyone here is happy to help, and you'll receive answers
quicker
and get more ideas/opinions when the whole list can see your mails.
Regards,
Oliver
Andrew Myers wrote:
Hi Oliver,
Just letting you know that I've commenced work on the Jar Tool again.
It's a bit more complicated than I first expected (processing wildcards
and
nested directories in particular). I wouldn't mind a bit of a hand
with
this, if anyone is willing to assist. My questions might be a little
"newbie-ish" so I wasn't sure whether to ask on the list or take it
off-list
with some nice person(s) who are willing to help out. What's the
protocol
here?
Thanks!
Andrew.
2009/5/12 Oliver Deakin <oliver.dea...@googlemail.com>
Hi Andrew,
Did you get the paperwork completed ok? Is there anything we can give
you
a
hand with?
Regards,
Oliver
--
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598. Registered office: PO Box 41, North Harbour, Portsmouth,
Hampshire
PO6 3AU
--
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
PO6 3AU
--
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
