We are using the zip feature of jfileupload to compress files before uploading to the server. In some cases an erroneous zip file comes through. This results in an exception similar to the following: java.util.zip.ZipException: invalid END header (bad central directory offset) at java.util.zip.ZipFi...

Here is the screen shot when a file from a non-read-only folder is uploaded.

Yes. This specific case was on a non-read-only folder. Actually files from the read-only folder were ok (except for sending up the path with the temp folder). That could be because they were being uploaded from the root folder on the drive.

Here is the applet tag: <APPLET CODE="jfileupload.upload.client.MApplet.class" JAVA_CODEBASE="./" ARCHIVE="/jfileupload/lib/jfileupload.jar,/jfileupload/lib/httpimpl.jar,/jfileupload/lib/chttpclient.jar,/jfileupload/lib/clogging .jar,/jfileupload/lib/batchui.jar,/jfileupload/lib/weakssl.jar" WIDTH="...

Well the only progress bar related parameter I see that we are using is "resetprogressbar". Which is set to true.

Is that what you meant?

So this parameter does modify the location where the .zip compressed file is created. But there is a new issue. For some files I am getting a NPE in the console and the applet hangs. Exception in thread "Thread-36" java.lang.StringIndexOutOfBoundsException: String index out of range: -9 at java.lang...

Well the documentation of that parameter says "...This parameter isn't allowed when resume support is enabled. "

We do need resume support as well as compression.

When we upload files from a read-only media we are getting an IO exception. This could be because the applet is trying to write chunks / zip file locally directly onto the read-only media. Any work-arounds for this? We could possibly specify the default java tmp folder for this purpose? Here is the ...

Thank you.

Thanks. That worked out. Another question I have around compression: is it possible to only compress files less than a certain size? The zipmaxsize parameter denies the request if it is above the threshold. What I would like is that for large files (several 100 MBs in size) we don't compress but sen...