SharpDevelop Community

I am creating a ZIP file using java.util.Zip and sending it to a system that is using SharpZipLib to open the file.  Despite the fact that the ZIP file can be opened by a myriad of archive utilities, this SharpZipLib is not able to open the ZIP file.

A problem appears to be in the CRC value -- the "Crc" is reported as being "-1" and "HasCrc" is "false".  When I view this ZIP in other archive tools, the CRC information shows up just fine.  There is also a "Flags" attribute with a value of "8" -- ZIP files that can be opened have a value of "0".

I am ZIP'ing only one file.  This should be pretty straight forward, and yet SharpZipLib seems to have an issue with java.util.Zip generated archives.

Is there something special that needs to be done when using java.util.Zip to create a ZIP file that can be opened by SharpZipLib?  Is there something SharpZipLib needs to do differently to open ZIP files generated by java.util.Zip?

Hi

We know that java cannot read zips that are created with the Zip64 extensions, for example by SharpZip, and this came up again the other day.

But this is the first time I have seen a problem reported in this other direction.

Not sure exactly what error you are seeing. Is there an exception? Have you tried running with the source code and seeing where this occurs? Or could you send me the file? I don't have java installed on this machine here.

Regards,
David

David,

The trick in this is that we do not have access to the system running this library.  We are in the process of working up a development test using this library so we can see what kind of error message happens.  As I understand things, the issue is that SharpZipLib appears to have an issue because it does not perceive that the ZIP file has any CRC information.  This is not so because I can get the CRC information through a variety of other tools.

If the information helps I know the version being used is "0.85.2.329".  I offer that as that is the information I have, and is not something I can change.

I will send the file once we sort out email addresses to use.

Thanks,

 John

Hi John,

Received the file, thanks for sending that. The good news or the bad news, depending on which way you look at it, is that zip file extracted fine without problem for me. I'm running the current 0.85.5 code of course, and this is the extract code I used ...

private void DoExtract(string sArchive, string password) {
    ZipFile zf = null;
    try {
        FileStream fs = File.OpenRead(sArchive);
        zf = new ZipFile(fs);
        if (!String.IsNullOrEmpty(password)) {
            zf.Password = password;
        }
        foreach (ZipEntry theEntry in zf) {
            if (!theEntry.IsFile)
                continue;
            String entryFileName = theEntry.Name;
            // or... String entryFileName = Path.GetFileName(theEntry.Name);

            byte[ ] buffer = new byte[4096];
            Stream zipStream = zf.GetInputStream(theEntry);

            String fullZipToPath = Path.Combine(@"c:\temp\", entryFileName);
            // unzip file in buffered chunks
            // the "using" will close the stream even if an exception occurs
            using (FileStream streamWriter = File.Create(fullZipToPath)) {
                StreamUtils.Copy(zipStream, streamWriter, buffer);
            }
        }
    } finally {
        if (zf != null) {
            zf.IsStreamOwner = true; // Makes close also shut the underlying stream
            zf.Close(); // Ensure we release resources
        }
    }
}

Why not download the dll and run the above code yourself and see that it works fine. You'll then be on more solid ground to advise the people who are receiving your file that the problem is at their end.

In the next post I'll copy the changelist since the 0.85.2 release.

This is the changes since the 0.85.2 release, one of which has presumably whatever problem they are seeing.

Changes for v0.85.5.452

• Fix for unreferenced ZipFile causing read failure after garbage collection.
• Fix to ZipInputStream.CloseEntry were skipping could fail for long values.
• Potential race condition flaw in FastZip event handling fixed up.
• Wrong exceptions being thrown and wrong arguments for some exceptions fixed.
• TarArchive handling tweaked so creation of archive with Tar streams is handled cleanly
• ZipFile Testing now handles directories better.
• DeflatorEngine altered so TotalIn is long.
• ZipInputStream handles initial reading for entries with no data better.
• Updates to unit tests
• BZip2Constants made internal. A breaking change in theory but no-one should be using these values.
• BZip2 QSort3 optimised somewhat by changing StackElement from class to struct as per lytico's suggestion.
• Name filters allow quoting of ';' characters using \;
• Fix GZIP flag checking bug
• ArgumentNull instead of NullReference in tar header now thrown.
• WindowsNameTransform now used in fastzip
• Disposed checking in ZipFile beefed up.
• Bug in entry handling for stored entries and sizing fixed.
• Zip entries with zero bytes written optimised.
• GZip Finish and Close no longer add extra footers. Close can be called twice without exception. Writes after finish/close now fail.
• Fastzip now throws exceptions if they arent 'handled' via delegates.
• TarBuffer.IsEofBlock made obsolete use static TarBuffer.IsEndOfArchiveBlock instead.
• Fix for Zip64 problems with streams that cannot seek.

Changes for v0.85.4.369 release

• Fix for encryption going awol in Zip archives sometimes.
• Help files updated and now generated by Sandcastle Help File Builder

Changes for v0.85.3.365 release

• Encrypting stored entries no longer consumes arbitrary amounts of memory.
• DeflatorOutputStream now uses CryptoTransform
• ZipInputStream detection of invalid sizes improved.
• ZipHelperStream reading end of stream values now correctly handled
• ZipHelperStream now supports reading/writing data descriptors.
• ZipFile testing data now handles data descriptors.
• ZipFile adding entries now correctly handles data descriptors.
• ZipFile now defaults to dynamic use of Zip64.
• ZipEntryFactory class made public and bugs fixed.
• ZipEntry DateTime handling cleaned up - Zero is treated as fixed low value and high values checked and handled.
• Added progress event handling to FastZip.

David,

Thank you.  We have downloaded the latest code and found that it works as expected.  Is there any chance we can get a copy of the stated version of the DLL so we can see if there is anything that can be done within that version to get this to work?  I will definitely pursue trying to get the other party to upgrade, but that is not within our direct control.

Thank you,

 John

Hi John,

I don't have any old DLL's I'm afraid. Looking through the release history, the release note for 85.2 was put out on 2007/06/28.

You would need to get the SVN from that point in time to reproduce that version of the code. This looks to be about revision 330 in the SVN.

Hope this helps,

David

Hi again John,

I will have a go at getting the source code at the 85.2 point-in-time from the SVN and emailing it to you, as it is probably much easier for me because I have the tools setup.

Regards,
David

Just confirming what I said in the email with the source. The 0.85.2.329 code extracts from your sample file without problem.

Regards,
David

I see you are hard coding the Length.

 byte[ ] buffer = new byte[4096];

We will be expecting huge zip files so this will not be feasible.

Our problem is with using the Length property when using ZipInputStream

zStream.Length

It thows an ZipException

Message = "Length not available for the current entry"

Chris,

The code creates a buffer of 4K which is the optimum size, and copies from stream to stream via this buffer.

Creating a buffer that is the size of the entire file is not scaleable, nor more efficient. This will soon hit memory limits, particularly when, as you say, "We will be expecting huge zip files".

The ICSharpCode.SharpZipLib.Core.StreamUtils.Copy method simply copies from input to output. You can replace 

StreamUtils.Copy(zipStream, streamWriter, buffer);

with

int n;
do {
    n = zipStream.Read(buffer, 0, 4096);
    streamWriter.Write(buffer, 0, n);
} while (n > 0);

That way you also avoid the need for a Length property which is as you say not available.

Regards,
David

David,

I appreciate your help!

Chris

Thanks for that, Chris. It's comments like yours that keeps us going on this forum.

Cheers,

David