ZipOutputStream and binary data

[JScoobyCed]

I used the zip package to create a Zip file. The list of files I put in the
archive was a set of binary data. After I use Winzip on the client side to
extract and get back the original files, they are differents. Those binary
data contains an internal CRC and when the system checks it, it fails. The
binaries are really big and I didn't analyse which byte could be wrong.
Both server and client use the same OS, and JRE 1.4.1_04

JScoobyCed
-------------

 

[Chris Smith]

I used the zip package to create a Zip file. The list of files I put in the
archive was a set of binary data. After I use Winzip on the client side to
extract and get back the original files, they are differents. Those binary
data contains an internal CRC and when the system checks it, it fails. The
binaries are really big and I didn't analyse which byte could be wrong.
Both server and client use the same OS, and JRE 1.4.1_04

Well, it's not the case that ZipOutputStream is universally broken, if
that's what you were expecting to hear. I've used it on several
occasions and it has worked fine for me, without fail.

Not to belabour the obvious, but to get any further we'd need to
actually see your code that's not working.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Andy Fish]

Well, it's not the case that ZipOutputStream is universally broken, if
that's what you were expecting to hear. I've used it on several
occasions and it has worked fine for me, without fail.

Not to belabour the obvious, but to get any further we'd need to
actually see your code that's not working.

I'd have to agree with chris. I've never seen a corruption from the java zip
functions.

try and find the smallest file that goes wrong, and then do a byte-by-byte
analysis - there's no other way to find out what the differences are, and
that's your best chance of working out where they came from.

analyzing it at this level will also force you to look real close at the
code and data, and it might even point you at some mistake in your code.

 

[Thomas Weidenfeller]

analyzing it at this level will also force you to look real close at the
code and data, and it might even point you at some mistake in your code.

My crystal ball tells me that something is wrong with the way the data
is read in the Java program before it is written to the zip file. Maybe
instead of using an InputStream the OP is using a Reader or some other
inappropriate class.

/Thomas

 

[Andy Fish]

My crystal ball tells me that something is wrong with the way the data
is read in the Java program before it is written to the zip file. Maybe
instead of using an InputStream the OP is using a Reader or some other
inappropriate class.

the strange thing is IIRC you normally just pass the names of the files into
the zip function - you don't have to read the file itself

 

[Roedy Green]

My crystal ball tells me that something is wrong with the way the data
is read in the Java program before it is written to the zip file. Maybe
instead of using an InputStream the OP is using a Reader or some other
inappropriate class.

See http://mindprod.com/fileio.html
for how to use GZIP (a sort of one-member zip file).

It uses the same guts as ZipFile.

When you get your code working with that, flip back to ZipFile.

 

[Liz]

See http://mindprod.com/fileio.html
for how to use GZIP (a sort of one-member zip file).

It uses the same guts as ZipFile.

When you get your code working with that, flip back to ZipFile.

I use GZIP and it is really great. Here is how I set up to read a 'csv' file
====
if (filename.endsWith("csv.gz"))
in = new BufferedReader(new InputStreamReader(new
GZIPInputStream(new FileInputStream(filename))));
else if (filename.endsWith("csv"))
in = new BufferedReader(new FileReader(filename));

 

[Chris Smith]

My crystal ball tells me that something is wrong with the way the data
is read in the Java program before it is written to the zip file. Maybe
instead of using an InputStream the OP is using a Reader or some other
inappropriate class.

This is fairly similar to what my own crystal ball is saying; that
there's probably an error in dealing with I/O streams somewhere.
Perhaps it's in the input, or perhaps it's in the output. Either way,
we won't know until we see the code.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[JScoobyCed]

Thanks all for your reply (I was off for a day, didn't check the news)
I think my code is really basic I/O with no Reader or Writer:

 

[JScoobyCed]

Thanks all for your reply (I was off for a day and didn't check the new).
I think my code is basic and there is no Reader or Writer. Or is the
BufferedInputStream creating problem ?

---------------------------------------------
public class ZipUtility {
private Vector files = null;
private String path, name;
public ZipUtility(String p, String n) {
path = p;
name = n;
}

public void addFile(File f) {
if(files==null)
files = new Vector();
files.addElement(f);
}

public void doZip() throws Exception {
FileOutputStream fo = new FileOutputStream(new File(new File(path),
name));
ZipOutputStream zo = new ZipOutputStream(fo);
byte[] buf = new byte[512];
BufferedInputStream bi;
int c;
File f;
for(Enumeration en = files.elements();en.hasMoreElements() {
f = new File(en.nextElement().toString());
bi = new BufferedInputStream(new FileInputStream(f));
zo.putNextEntry(new ZipEntry(f.getName()));
while((c = bi.read(buf)) != -1) {
zo.write(buf);
}
zo.flush();
zo.closeEntry();
bi.close();
}
zo.close();
fo.close();
}
}

 

[Thomas Weidenfeller]

the strange thing is IIRC you normally just pass the names of the files into
the zip function - you don't have to read the file itself

Your memory is wrong. You know the drill: Read the API ... ))

/Thomas

 

[Chris Smith]

while((c = bi.read(buf)) != -1) {
zo.write(buf);
}

That's the problem. read(byte[]) is specified to read at least one byte
into the byte array (unless it's at end of file), and then return the
number of bytes read. You're assuming that it always reads 512 bytes at
a time, and so writing the entire buffer to the output stream. Try the
following instead:

while ((c = bi.read(buf)) != -1)
{
zo.write(buf, 0, c);
}

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Roedy Green]

That's the problem. read(byte[]) is specified to read at least one byte
into the byte array (unless it's at end of file), and then return the
number of bytes read. You're assuming that it always reads 512 bytes at
a time, and so writing the entire buffer to the output stream. Try the
following instead:

The problem is you write erroneous code, and it will most of the time
work. This leads you into false sense of security.

I got nailed myself on this the other day reading GZIP stuff which
does not give you all you ask for at a pop even with purely in-RAM
ByteArrayStreams.

 

[JScoobyCed]

The problem is you write erroneous code, and it will most of the time
work. This leads you into false sense of security.

I got nailed myself on this the other day reading GZIP stuff which
does not give you all you ask for at a pop even with purely in-RAM
ByteArrayStreams.

Thanks all. I got it working by changing the method to write in the file
--> zo.write(buf,0,c);

I should have found this myself....


JScoobyCed
-------------