The fact that available() returns 1 doesn't mean anything - if you look at the source code for ZipInputStream, 0 and 1 are the only values that method can return. The available() method is rarely useful for anything, really.
Unfortunately I don't see where the problem is in your code. Does the "bytelength:" message appear at all?
One thing you might try doing is taking out the ZipInputStream, and try to copy the content to a file without uncompressing it. Then you can see if what con.getInputStream() is giving you is a valid zip file or not. (Just try opening it with another too, like Windows Explorer - or if you're on UNIX, the jar tool can work as well.) If nothing else, it will help narrow down where the problem is.
Ah, I think you probably need to use the getNextEntry() method to iterate through all entries in the file - even if there's just one. Remember, a zip file can contain multiple files within it. It should be something like this:
"I'm not back." - Bill Harding, Twister
Joined: Oct 13, 2007
(1.) >>>>> ...... Does >>>>> the "bytelength:" message appear at all? No, it doesn't
(2.) If I do this below, then I will get the byteLength and I will get the output in a file but the file is filled only with weird characters. I think because it's a zip file.
(3.) And I can download and uncompress the zip file okay manually.
Well, I think there's a major mistake on this line:
while ( (byteLength = tempStream.read(input_buffer, 0, 1024)) > 0 )
That ought to be "zip_in_stream", there, not tempStream. My theory is that when you open the ZipInputStream, is asks the BufferedInputStream to read a little data to make sure this is a zip data stream. BufferedInputStream reads much more data than requested, and stores it internally; this is what a BIS does. Then when you try to read tempStream directly, most of the file data has already been read, and you're just getting the tail of the stream -- in fact, the "tail" may be zero-length, if the amount of data is less than the buffer size.
I have tried "zip_in_stream". The "byteLength" message doesn't appear at all. And the destination output file is empty
[ January 15, 2008: Message edited by: Susan Smith ]
Joined: Jan 30, 2000
I overlooked the use of tempStream - yes, that should definitely be zip_in_stream if you want to uncompress. However you still need to use the getNextEntry() method as I suggested in the last post. Otherwise the results are exactly as you describe: the ZipInputStream will appear to have no bytes to read.