Wrong password exception for correct password


When I try to to read the content of the zipped file 562E0101.STM in 562E0101.ZIP I get exception "Bad password".
However, the password is correct. I am able to unpack with it when using WinRar, WinZip, Total Commander (unzip), even SharpZipLib works just fine (I suggest you take a look into their code).
Try to decompress the file attached with 6chars long password: 472713
The code I use:
        using (ZipFile zip = ZipFile.Read(filePath))
            zip.Password = password;
            foreach (ZipEntry e in zip)
                string entryName = Path.GetFileName(e.FileName);
                string entryNameWithoutExtension = Path.GetFileNameWithoutExtension(entryName);
                if (entryNameWithoutExtension.Equals(fileNameWithoutExtension))
                    e.Extract(tmpFolder, ExtractExistingFileAction.OverwriteSilently);
                    return Path.Combine(tmpFolder, e.FileName);

file attachments

Closed Jul 11, 2011 at 11:37 AM by Cheeso
No response; closed as not-a-bug.


Cheeso wrote Jun 13, 2011 at 8:22 PM

Hmm, this is a strange bug. I tried unzipping the zipfile in question, using DotNetZip and the password you provided, and sure enough, it failed with a "Bad Password" exception. I then tried unpacking the zipfile in question with Windows Explorer, using the same password, and got the same failure. "Bad password"

At this point I am not certain that the password you provided actually matches the zipfile you provided.

I understand that you said that you unpacked it using various other tools. I am only telling you what I TRIED. I also tried WinRar, and as you reported, WinRar successfully unpacked the zip file.

When I ran the test with DotNetZip again, and stepped into the code, I found that DotNetZip was failing your password based on a mismatch between the last byte of the "decrypted header" and the high-order byte of the CRC for the entry. This is a requirement of the PKWare spec, see AppNote.txt for details. In some cases when bit 3 is set in the general purpose bitfield, the last byte of the decrypted header must match the high-order byte of the last-modified time. This is not mentioned in appnote but is a convention employed by infozip, so I use it also in DotNetZip. But in your case bit 3 is not set, and there is a mismatch anyway between these bytes anyway.

So ... I conclude that your password is not correct; your zipfile does not comply with the PKWare AppNote specification nor the other "InfoZip" convention that is in common use. It could be that these other tools and libraries to not enforce this aspect of the specification, I don't know for sure. But it does seem to me that your zip file is broken.

how did you create it? What tool or library did you use? If you create a zip with windows explorer "Compressed folders" with a password, I think it will correctly be unpacked by DotNetZip. If you create a zip that is compliant with the spec, then I think it will be correctly unpacked by DotNetZip.

Let me know.

For now, the behavior you reported is "as documented" and "as expected". From what I can see, this is not a bug in DotNetZip.

wrote Jun 14, 2011 at 1:02 AM

wrote Jul 11, 2011 at 11:37 AM

wrote Feb 22, 2013 at 1:43 AM

wrote Mar 8, 2013 at 2:55 AM

erickwidya wrote Mar 8, 2013 at 2:55 AM

it's been old post but i have this strange behaviour too

when using dotnetzip i can't extract it, "Bad Password , the password did not match"
when i extract using windows explorer also the password did not match

but when i used 7zip, it can be extracted..



erickwidya wrote Mar 8, 2013 at 3:11 AM

sorry, forgot the password

the password = [PA219909PA]

wrote May 16, 2013 at 12:31 PM