SharpDevelop Community

I'm using SharpZipLib version 0.85.5 to unzip files. My code has been working nicely for a couple of months until I found a ZIP file that it doesn't like.

ICSharpCode.SharpZipLib.Zip.ZipException: End of extra data     
        at ICSharpCode.SharpZipLib.Zip.ZipExtraData.ReadCheck(Int32 length) in C:\C#\SharpZLib\Zip\ZipExtraData.cs:line 933     
        at ICSharpCode.SharpZipLib.Zip.ZipExtraData.Skip(Int32 amount) in C:\C#\SharpZLib\Zip\ZipExtraData.cs:line 921     
        at ICSharpCode.SharpZipLib.Zip.ZipEntry.ProcessExtraData(Boolean localHeader) in C:\C#\SharpZLib\Zip\ZipEntry.cs:line 925     
        at ICSharpCode.SharpZipLib.Zip.ZipInputStream.GetNextEntry() in C:\C#\SharpZLib\Zip\ZipInputStream.cs:line 269     
        at Constellation.Utils.Tools.UnzipFile(String sourcePath, String targetDirectory) in C:\C#\Constellation2\Utils\Tools.cs:line 90     
--- End of inner exception stack trace ---

Here is my unzip method:

     public static void UnzipFile(string sourcePath, string targetDirectory)
     {
        try
        {
            using (ZipInputStream s = new ZipInputStream(File.OpenRead(sourcePath)))
            {
                ZipEntry theEntry;
                while ((theEntry = s.GetNextEntry()) != null)
                {
                    //string directoryName = Path.GetDirectoryName(theEntry.Name);
                    string fileName = Path.GetFileName(theEntry.Name);

                    if (targetDirectory.Length > 0)
                    {
                        Directory.CreateDirectory(targetDirectory);
                    }

                    if (fileName != String.Empty)
                    {
                        using (FileStream streamWriter = File.Create(targetDirectory + fileName))
                        {
                            int size = 2048;
                            byte[ data = new byte[2048];
                            while (true)
                            {
                                size = s.Read(data, 0, data.Length);
                                if (size > 0)
                                {
                                    streamWriter.Write(data, 0, size);
                                }
                                else
                                {
                                    break;
                                }
                            }
                        }
                    }
                }
            }
        }
        catch (Exception ex)
        {
            throw new Exception("Error unzipping file \"" + sourcePath + "\"", ex);
        }
    }

The file unzips fine using XP's built-in ZIP support, WinZIP, and 7-Zip. The exception is being thrown at s.GetNextEntry().

#Zip doesnt like some of the extra data for an entry which may be invalid but tolerated by other archivers by the sound of it.

 

Thats the theory anyway :-)

You could hack the library to ignore this if you want - ProcessExtraData is called to handle some less common ways of storing dates mainly, and isnt really required to extract any data (well unless the files are really big that is - Zip64 data is stored there also).

hth, -jr-

Thanks How big is "really big"? My app is dealing with some zips that approach 2 GB.

Hi,

For Zip files really big means greater than 2^32 or 4GB.

Given you are getting close to the boundary on occasion it might be smarter to find out what is going wrong in your header and try and sort it out better.  Was it just one file or is it happening a bunch?

hth, -jr-

It's just one file out of many that are working correctly. Unfortunately, I don't have control over the files as we get them nightly from a third party.

It would be useful to try and work out whats going on.

For one thing getting the correct information in the header is nice but its a pain when trying to do so stops you getting the data you want.

It will be possible to allow the header information degrade or let the errors be ignored in some fashion and allow the data to be read.  The question is how to do that in a clean manner.

Two questions spring to mind.

1. What program is generating the file?  Not that important but useful to know.

2. What is #Zip complaining about in the data?

Do you still have the file that failed? (Ok three questions)

Cheers,

-jr-