I am trying to use the zip stuff in vjslib in Visual C++ .NET 2003, but I'm
having problems with the read(byte[], int, int) and read(byte[]) methods. For
some reason, when I try (source code to put this in context is at bottom):

zipStream->read(fileBytes); or
zipStream->read(fileBytes, 0, fileBytes->Length);

then reading stops after 500ish bytes (the number varies for different files
but remains the same for the same file attempted multiple times), but if I
use:

for (int j = 0; j < fileBytes->Length; j++)
{
fileBytes[j] = zipStream->read();
}

then the whole file gets read fine. The same is also true if I redo the code
to use the ZipFile.getInputStream(some zip entry).read methods. Does anyone
know what's up?

Code:
ZipInputStream* zipStream = new ZipInputStream(new
FileInputStream("test.zip"));
ZipEntry* currentEntry;
while ((currentEntry = zipStream->getNextEntry()) != 0)
{
signed char fileBytes __gc[] = new signed char
__gc[currentEntry->getSize()];
//insert file reading code
FileStream* currentFileStream = File::Create(currentEntry->getName());
currentFileStream->Write(fileBytes, 0, fileBytes->Length);
currentFileStream->Close();
}
zipStream->close();

The same happens with the J# 2.0 beta that comes with some of the VS
Expresses, but I tried it out on real Java, and I was surprised to see that
the same behavior occured since I counldn't find any word of it in Sun's
documentation. All examples I've found with Google pound the read(Byte[])
method with a while loop, but no one seems to consider it a bug that it would
just stop reading when there's still bytes to be read and array space to read
into. Perhaps it's some sort of Java common knowledge that I'm unaware of. I
think I'll check out SharpLibZip.

I think the last param of "read" is the MAX buffer size you pass to the
"read" method, it doesn't mean it should read that much data. So you do have
to call read many times (see if it returns some value saying how much bytes
it read and then see how much you have to still read to get the file)

I haven't used Java's I/O stuff for some time now, but I think the COMM API
was behaving like that

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
George Birbilis <birbilis (AT) kagi (DOT) com>
Microsoft MVP J# for 2004, 2005
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ QuickTime controls (Delphi & ActiveX: VB, PowerPoint, .NET)
+ Plugs (InterProcess/Internet communication)
+ TranXform (VB6 form to ASP.net WebForm convertion)
http://www.kagi.com/birbilis
+ Robotics
http://www.mech.upatras.gr/~robgroup
.................................................. .......................

What situations exist in which reading less than the requested maximum is
advantageous?
"George Birbilis [MVP J#] [9880]" <birbilis (AT) kagi (DOT) com> wrote

when you have streaming and want to return as soon as possible without
blocking for too much time