DotNetZip Work Item Rss Feed

Commented Issue: Size of extracted file does not match the uncompressed size recorded in the zip file [16173]

johnbuuck — Thu, 16 May 2013 19:49:40 GMT

When the attached file, TestZipItBug.dat, is added to a zip file using ZipIt with all default options, the resulting entry in the zip file cannot be extracted with the Ionic.Zip.dll or with standard WinZip. WinZip reports the following:

Extracting to "C:\Temp\"
Use Path: yes Overlay Files: no
Extracting testzipitdeflatebug.dat
CRC check failed
Error: Unable to extract "C:\Temp\testzipitdeflatebug.dat".

The size of the extracted file (2686976) does not match the uncompressed size (3080192) recorded in the Zip file

NOTE: This also happens when using "-C none" option to avoid compression. However, if "-C bzip" is used, then the resulting zip entry extracts ok.
Comments: ** Comment from web user: johnbuuck **

I assume that Ionic.zip is intended to successfully zip/unzip any file (within size constraints). If so, then it seems this issue should have very high importance since it provides a known case where it fails (without being due to any unusual options or other environmental issues). I ran across another file that failed in the same way but it can't be attached here because the attachment limit here is 4MB and the file is 20MB.

Commented Issue: Degrade gracefully when filenames cannot be encoded in selected code page [10843]

airboy — Sat, 11 May 2013 11:23:25 GMT

If I zip this file and leave UseUnicodeAsNecessary as FALSE the following happens:

Windows Explorer: Can not open it.

WinRar/WinZip: Can open it, but has weird names, and the Sub Folders do not work at all which is a problem

------------------------------------------

I also did some testing in Gmail with similarly named files. Gmail allows you to download attachments as a zip and it automatically detects that the characters are valid for a zip file and asks you What country you would like to compress it for. Selecting English will take out all illegal characters and replace them with underscores. This is something that I wish the dot net zip library did for me.
Comments: ** Comment from web user: airboy **

sorry for the double post... but i want to add that there is no need of using
zip.UseUnicodeAsNecessary = false;
just not use this...
hope it helps...

Commented Issue: Degrade gracefully when filenames cannot be encoded in selected code page [10843]

airboy — Sat, 11 May 2013 11:22:27 GMT

use the following parameters before zipping

zip.AlternateEncodingUsage = ZipOption.
zip.AlternateEncoding = Encoding.GetEncoding(737);

that helped me with a lot of Greek Characters...
;)

Commented Issue: ZipFile.AddFile fails depending of the file size. [14087]

bob0043 — Fri, 03 May 2013 18:27:57 GMT

AddFile truncate the entry, and Extract trow an exception "bad read of entry test/MyFile.txt from compressed archive."

Debugging step by step sometimes work fine.

My code:

Private Sub Button3_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button3.Click
Dim str As New String(" "c, 2490368)
IO.File.WriteAllText("C:\test\MyFile.txt", str)
End Sub

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
Using zip As New Ionic.Zip.ZipFile
zip.AddFile("C:\test\MyFile.txt")
zip.Save("C:\test\MyZip.zip")
End Using
End Sub

Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.Click
Using zip As Ionic.Zip.ZipFile = Ionic.Zip.ZipFile.Read("C:\test\MyZip.zip")
For Each arch As Ionic.Zip.ZipEntry In zip
arch.Extract("C:\test\opened")
Next
End Using
End Sub
Comments: ** Comment from web user: bob0043 **

I concur with rhpainte's as to the location of the problem but differ slightly as to the analysis and fix.

The number of buffers used is partially dependent on the number of processors. Each set of buffers is handled by a separate thread. The variables _latestCompressed, _lastFilled, and _lastFilled keep track of, respectively, the last buffer that has been compressed, the last buffer that has been filled with input awaiting compression, and the last buffer written to the output.

The code is such that _latestCompressed <= _lastFilled is always true. The devil is in that "<" part of the expression. The EmitPendingBuffers functions, as written, is exiting when _lastWritten == _latestCompressed but that may not be the *last* buffer that needs to be written -- the last to be written should be _lastFilled. There is a race condition here: depending on input file size, buffer count, thread count, processor workload, and the phase of the moon, the _latestCompressed may or may not be equal to _lastFilled when EmitPendingBuffers checks it.

So the fix should be:
change
} while (doAll && (_lastWritten != _latestCompressed));
to
} while (doAll && (_lastWritten != _lastFilled));

This is in function EmitPendingBuffers. In the copy of the source I have that is line 971 of ParallelDeflateOutputStream.cs. Rhpainte notes it as line 987 of the same file.

Using "} while (doAll && (_lastWritten != _latestCompressed || _lastWritten != _lastFilled));", as rhpainte suggested, has a an "extra" check: if (_lastWritten == _lastFilled) is true then (_lastWritten == _latestCompressed) is also true (only compressed buffers are written) and there is no need to check it.

Commented Issue: CRC Error when compressing and decompressing mp3 VBR file [14623]

bob0043 — Fri, 03 May 2013 17:46:11 GMT

I am having issues with just one file that has been compressed with DotNetZip 1.9. Using supplied example project "CreateZip" it fails to decompress a mp3 VBR file. It doesn't matter which utility is used for decompressing, be it Windows Zip, WinZip, WinRar, 7z, and of course DotNetZip.

It seems to work under any of these conditions though:
1. Disable the parallel processing explicitly: zip.ParallelDeflateThreshold = -1
2. Set the compression level to None: zip.CompressionLevel = Ionic.Zlib.CompressionLevel.None

Note: when I try to compress the same file using another of the above tools it works ok.

For copyright matters I cannot upload the file but if the reviewer requires it, please send me a message and will reply accordingly.

Thank you.
Comments: ** Comment from web user: bob0043 **

Re: buffer size. The documentation (xml comments) *says* the buffer size is 128k but the *code* actually sets the buffer size to 64k. The problem appears to be a "race" condition that will mostly likely exhibit the problem if the input is an exact multiple of the buffers size but *may* occur even if it is not a multiple.

When I encountered the problem in code I wrote it took a bit to realize the problem was actually in the zip library. My program (a Windows service) zipped a file, copied the zip file to a server, unzipped the archive and compared it to the original. Some small fraction of the time it would work fine; this led me to think there was a race condition -- it just took a while to track down the culprit.

I then wrote a "driver" that did only the zip and unzip. This program almost *never* failed when applied to a 16MB file. I put the zip/unzip inside a loop; if the loop max was greater than 1 it *almost* always failed but would occasionally get through 2 iterations before failing.

The fix proposed by rhpainte at http://dotnetzip.codeplex.com/workitem/14087 will fix the problem.

Created Issue: Incomplete list of entries in zip [16188]

janba — Fri, 03 May 2013 09:12:48 GMT

When reading in the attached zip with the following simple code, the entries list only contains one entry when it should contain 3. Unzipping and zipping the zip again removes this problem, so there's likely some form of corruption going on. Unfortunately, there is no exception being thrown when reading it. It would be great if this kind of corruption could be detected as handled with an exception.

using (ZipFile zip = ZipFile.Read(filepath))
{
foreach (ZipEntry content in zip)
{
// do stuff
}
}

Commented Issue: OverflowException when accessing zip file twice [16183]

janba — Fri, 03 May 2013 09:07:15 GMT

Hello everybody,

I started using DotNetZip in my application but I have problem when I want to use a zip file twice within my application. For example, first I read my zip file and display the content in my application.

```
using (ZipFile zip = ZipFile.Read(zipPath))
{
...
}
```

Then later, I want to extract the same zip file, therefore I use the same code above and read the zip file into 'zip'. But then I receive an OverflowException:

```
Zip File Error: Cannot read that as a ZipFileSystem.OverflowException: overflow while creating filename
at Ionic.Zip.ZipEntry.CopyHelper.AppendCopyToFileName(String f)
at Ionic.Zip.ZipEntry.ReadDirEntry(ZipFile zf, Dictionary`2 previouslySeen)
at Ionic.Zip.ZipFile.ReadCentralDirectory(ZipFile zf)
at Ionic.Zip.ZipFile.ReadIntoInstance(ZipFile zf) ; File
```

When I close the application and start again, I can do the first step again but not the second. This happens to me every time I start reading to a zip file the second time.

Any idea why I get this exception? Thanks in advance.
Comments: ** Comment from web user: janba **

I'm experiencing exactly the same problem. In my case though I'm trying to read 3 zips (a test sample really) and only one of them fails. As such I looked into it a bit closer and here are some results:

- The file name is irrelevant. I renamed it even to x.zip and it still doesn't work.
- Renaming the file between the first and second scan (I'm iterating through a folder) does not change anything, there's still an exception on the 2nd pass

So, if it's not the file name of the zip, it sounds like it must be the file names within the zip. And yep, that's it. Here's what's causing it:

Duplicate file names inside the zip. For some bizarre reason the zip file causing this exception had two files with the same name (both in the root of the zip) inside. Now, I'd understand there being an exception for this, but if there is it should happen on both passes, not just the second and consecutive. Please make this behavior consistent and either throw an exception always or never. I vote for never as reading the zip works fine despite the duplicates, it's just extracting it that would cause problems.

Commented Issue: name clash possible with temporary file during extraction [14097]

aquariusquintini — Thu, 02 May 2013 18:29:29 GMT

Ok let me try to explain it better.

Suppose I have a zip file which contains: helloworld.txt test.txt

Now suppose I try to extract this zipfile into a directory, c:\Test . What happens is, for each file in the zipfile the library creates a filename.ext.tmp while he unpacks the specific file of the ze.Extract. That means, when it extracts helloworld.txt on ze.Extract(...); in the folder c:\test\ there will be a file called helloworld.txt.tmp till extract finishes.

A problem occurs when C:\test already has a file called helloworld.txt.tmp . If that happens, the library just fails with a message stating that the file already exists (the helloworld.txt.tmp, not the helloworld.txt).
Comments: ** Comment from web user: aquariusquintini **

Hello,

Same issue here.

I added the following hack/workaround to our code until this issue is fixed in the Ionic library

The hack version:
```
using (var zipFile = ZipFile.Read(filePath))
{
foreach (var entry in zipFile.Entries)
{
var extractPath = Path.Combine(unzipPath, entry.FileName);
var extractTmpPath = string.Concat(extractPath, ".tmp");

// Check if the temp file already exists
if (File.Exists(extractTmpPath))
{
// Remove the temp file
_Log.Info("Deleting existing temp file ({0}) to prevent problems with extraction.", extractTmpPath);
File.Delete(extractTmpPath);
}

// Extract the actual file from the zip.
entry.Extract(unzipPath, ExtractExistingFileAction.OverwriteSilently);
}
}
```

The original code:
```
using (var zipFile = ZipFile.Read(filePath))
{
zipFile.ExtractAll(unzipPath, ExtractExistingFileAction.OverwriteSilently);
}
```

Created Issue: OverflowException when accessing zip file twice [16183]

lolkuro — Mon, 29 Apr 2013 07:48:01 GMT

Created Issue: Size of extracted file does not match the uncompressed size recorded in the zip file [16173]

johnbuuck — Tue, 23 Apr 2013 13:15:12 GMT

Created Issue: CreationTime is incorrect [16154]

MountainMan69 — Sat, 13 Apr 2013 15:03:43 GMT

I am having trouble accessing the creation date of files in a zipped file. The file creation time is correct but the creation date is
always equal to the current date. Other fields like ModifiedTime are correct.

The following code illustrates the problem.
```
using (ZipFile zip = ZipFile.Read(zippedFile))
foreach (ZipEntry zipEntry in zip)
{
string standardizedZipName = zipEntry.FileName.Replace('\\', '/');
if (zipEntry.IsDirectory)
{ //path name
Console.Write("Directory: " + zipEntry.FileName
+ " Created " + zipEntry.CreationTime.ToString());
} //ends path name
else
{ //file name
Console.Write(" " + zipEntry.FileName
+ " Created " + zipEntry.CreationTime.ToString()
+ " Modified " + zipEntry.ModifiedTime.ToString()
+ " Last modified " + zipEntry.LastModified.ToString());
} //ends file name
} //ends foreach (ZipEntry...
```
The output shows:
Running on 4/13/2013 9:37:15 PM
jigo-src-2.1.1/build.xml Created 4/13/2013 2:46:28 PM Modified 2/7/2003 8:07:50 AM Last modified 2/7/2003 12:07:50 AM
Directory: jigo-src-2.1.1/conf/ Created 4/13/2013 2:46:28 PM
jigo-src-2.1.1/conf/jigo.pro Created 4/13/2013 2:46:28 PM Modified 1/28/2003 8:37:17 AM Last modified 1/28/2003 12:37:18 AM
jigo-src-2.1.1/conf/packages.txt Created 4/13/2013 2:46:28 PM Modified 1/28/2003 8:31:43 AM Last modified 1/28/2003 12:31:44 AM
jigo-src-2.1.1/conf/README Created 4/13/2013 2:46:28 PM Modified 1/28/2003 7:47:38 AM Last modified 1/27/2003 11:47:38 PM
Directory: jigo-src-2.1.1/docs/ Created 4/13/2013 2:46:28 PM

I am running Ionic.Zip.dll 1.9.1.8 using C# Microsoft VS 2012 Express on Windows 8 but have the same problem on a Windows 7 system
using VS 2012.

Any suggestions?

Commented Issue: ZipFile.AddFile fails depending of the file size. [14087]

divo — Thu, 11 Apr 2013 18:05:29 GMT

@iosifpetre: There is no way to recover the zip archive once it is corrupted. That is why this issue is so critical. I'd recommend using another zip library like SharpZipLib or the functionality included in the current .NET Framework version.

Commented Issue: ZipFile.AddFile fails depending of the file size. [14087]

iosifpetre — Thu, 11 Apr 2013 16:31:35 GMT

mohammadforutan, is nice that "zip.ParallelDeflateThreshold = -1" resolved your issue but how do I extract the files, that is when you create the file, but how to fix to get the file, I need the data from the files archived..
please help

Created Issue: DotNetZip created zip does not open on double click[opens using 7 zip extract] [16141]

vivekbh — Thu, 04 Apr 2013 12:21:41 GMT

DotNetZip created zip does not open on double click[opens using 7 zip extract].

After downloading the zip, if we double click on zip, error pops up,

Windows cannot open the folder
The compressed(zipped) folder is [folder name] invalid.

But if we extract downloaded zip using 7 Zip it displays proper files.

The code used is,

string archiveName = String.Format("archive-{0}.zip", DateTime.Now.ToString("yyyy-MMM-dd-HHmmss"));
Response.ContentType = "application/zip";
Response.AddHeader("content-disposition", "filename=" + archiveName);
using (ZipFile z = new ZipFile())
{
z.AddEntry("test1.csv",csvData);
z.Save(Response.OutputStream);
}
Response.Flush();
Response.Clear();

Please let me know if anyone has any idea about this.
Thanks

Created Issue: Rename entry problem [16130]

Virtlink — Thu, 28 Mar 2013 22:35:50 GMT

In the Reduced v1.9.1.8 DotNetZip release there is an issue with renaming an entry.

__To reproduce__
1. Use another archiver program to create a ZIP archive that contains an entry with a full Windows path (e.g. `C:\Users\Test\Documents\myfile.txt`).
2. Let DotNetZip open the archive, rename the file, and save the archive.
3. The archive now contains _two_ files that seem to point to the same entry. One with the old filename, one with the new filename.
4. WinRAR thinks the archive is corrupt, 7zip and Windows Explorer will extract either of the two files.

__The code (for step 2)__
```
using (ZipFile zip = ZipFile.Read("test.zip"))
{
ZipEntry entry = zip.Entries.FirstOrDefault(e => Path.GetFileName(e.FileName) == "myfile.txt");
entry.FileName = Path.Combine(Path.GetDirectoryName(entry.FileName), "newfile.txt");
zip.Save(@"test2.zip");
}
```

__The underlying cause__
When renaming an entry the entry with the old filename is removed from `_entries`. However, it uses the normalized filename as the key to remove, but `_entries` (and the entry's `Filename` property) sometimes contains the unnormalized filename (read directly from the file). So the old entry doesn't get removed. It doesn't check that exactly one key-value pair is removed.

This issue was first encountered by a user who posted a [question on Stackoverflow](http://stackoverflow.com/q/15601189/146622).

Commented Issue: ZipSL runtime error - TypeInitializationException due to IBM437 Encoding defaults [14049]

KeithW — Tue, 19 Mar 2013 11:39:43 GMT

Hi,

Awesome library! Got up and running in seconds - you've certainly led we customers into the "Pit of Success." :)

This may be already known, but I encountered runtime TypeInitializationException(s) when using types (such as ZipFile and ZipEntry) in ZipSL 1.9.1.8 from with a Silverlight application. After building and running from source, it was clear that the problem
was related to the static type construction at lines such as:

AlternateEncoding = System.Text.Encoding.GetEncoding("IBM437");

Appears this encoding is not one of the
four supported encodings in SL4. I was able to avoid the issue by altering the behavior where necessary with preprocessor directives, for example:

#if SILVERLIGHT
AlternateEncoding = System.Text.Encoding.GetEncoding("utf-8");
#else
AlternateEncoding = System.Text.Encoding.GetEncoding("IBM437");
#endif

I was able to do this to the point where my use cases were covered; would be happy to submit a patch if I had some guidance on the most appropriate strategy for dealing with this.

Yours,
David
Comments: ** Comment from web user: KeithW **

Just adding some support for this patch, would love to get it in the next release.

Created Issue: the final hash has not been computed [16105]

apelkster — Fri, 15 Mar 2013 03:58:57 GMT

Recently I have run into a few zip files which were created using DotNetZip which I cannot unzip with DotNetZip but I can unzip with WinZip. In each case, the unzip stops with an error that reads: "the final hash has not been computed". I have tried unzipping the same with the DotNetZip-WinFormsTool.exe that comes with the Development Kit and it too produces the same error.

The error happens consistently and at the same point each time. I looked at the particular file in the .zip that it fails on and can find nothing wrong with it (after extracting it using WinZip). Unfortuneatly, the three files that I can reproduce the problem with are each larger than 4MB so I cannot attach them to this post.

I found posts related to the same problem but no resolution. Any ideas?

Commented Issue: Feature Request: LZMA (7 Zip) Support [14034]

CreepyGnome — Thu, 14 Mar 2013 18:53:37 GMT

Greetings,

I would like to request support for LZMA implemented with the same design you use for your Zip implementation from a class point of view. So that someone who uses your Zip library can easy pickup and use your LZMA one. With the AES128 and AES256 encryption options.

There is a C# LZMA reference implementation that is Public Domain on the 7-zip.org site's SDK:
http://www.7-zip.org/sdk.html

Also the SevenZipSharp project here on codeplex has a managed C# implementation based on the reference one. It is not a compatible license but the owner is very reasonable and if you ask he will most likely give you permission to fork his LZMA managed implementation under Ms-PL, as he has given to me.

I use your library to do all the Zip and GZip needs, and I use the other for my LZMA needs but the SevenZipSharp managed implementation needs some work performance wise, and it lacks encryption. I was planning to do that if I have time, but that would still give me two libraries, so I figured I could at least ask if you could include this into your Library that would help reduce everything for me to a single library under an active and well maintained project which would be great.

Kind Regards...
Comments: ** Comment from web user: CreepyGnome **

bump

Any possibility of this being implemented?

Created Issue: Name Clash of the Temp Files [16103]

JeffOstrosser — Thu, 14 Mar 2013 14:37:24 GMT

Our applicaiton is creating hundreds of ZIP files on the fly using several worker threads to do this. Each worker thread has its own directory to work in, and each new ZIP file is created in this directory. We have used the ZIP class property TempFileFolder to have ZIP create the temp files in separate directories for each worker thread.

But what we have found is that the tmp file created by the ZIP class are still suffering name clashes. It could be that the algoritm for determining temparary file names is not discrete enough to come up with unique names in such a rapid progression as we are genrating ZIPs at a rate of 6 - 10 per second. Or if the tempary file name is based on the source file it could be that since the source files differ by only a singe character, the temparay file name's hash value is not unique?

Either way can you offer a hint or tip that might help us work around this issue?

Commented Issue: "Path is empty" when extracting in a linux system. [15236]

edgarrc — Wed, 13 Mar 2013 17:51:38 GMT

When using the following code:

ZipFile zip = ZipFile.Read(ms);
zip.ExtractAll(LatestPath);

An "Path is empty" exception message is triggered by that DotNetZip tries to pass "" to Directory.Create() in ZipEntry.Extract, line 760.

The cause is that the variable targetFileName contain the path using "\" as directory separator. When run on linux the path is interpreted as a single filename making the directory path "".

I would guess it could be fixed in the method ValidateOutput() in the same file line 1417:
- outFileName = outFileName.Replace("/","\\");
+ outFileName = outFileName.Replace('/', Path.DirectorySeparatorChar);

It works but someone who knows it should have a look at it.
Comments: ** Comment from web user: edgarrc **

Thank you, I hope this fix is already merged on main stream, worked perfectly on linux-mono.