Zipped File asks for password even though password wasn't set

Oct 28, 2009 at 11:55 PM

When I unzip a file created by dotNetZip, it asks me for a password even though I didn't set one.  The other weird issue is that it only happens sometimes.  I can't figure out what could be causing it.  Any ideas?

I am using version 1.8.4.21

Code

            ZipFile zipfile = new ZipFile(zipFileName);//create zip named zipFileName.zip     
            zipfile.AddDirectory(sourceFolder,subfoldername);//add the sourceFolderContents to the zip file

            
            var pathToZip = destinationFolder + "\\" + zipFileName;
            zipfile.Save(pathToZip);//save file in the destination folder

Coordinator
Oct 29, 2009 at 2:25 AM

Hi there.

How do you unzip the file?  using what?   What "asks you" for a password?

That code you show - do you have a using clause?   or a try...finally?   The ZipFile is IDisposable.  Do you call ZipFile.Dispose()?  You need to, when you're done. Look at any example - it will show how to do it. 

From time to time there are bugs uncovered in the library.  But I don't recall anything like this.  I run lots and lots of tests, every  time I post a release, and I never get a "ask for a password" when there was no password used.  

The first thing I would do, if I were you, is tighten up that code, and do a little more research on just when it asks for a password, and when your zip opener doesn't.  Narrow it down.

I'm glad to help in any way. If you can show me code that reliably produces a broken zip file, I am definitely interested in that.

-Cheeso

 

Oct 29, 2009 at 2:30 AM
I'm using the built in windows zip program to unzip the file.  That program prompts me for a password when I unzip the file.  I am not calling ZipFile.Dispose().  I'll make that change, run some tests, and let you know what I find out.

Thanks.

On Wed, Oct 28, 2009 at 10:25 PM, Cheeso <notifications@codeplex.com> wrote:

From: Cheeso

Hi there.

How do you unzip the file?  using what?   What "asks you" for a password?

That code you show - do you have a using clause?   or a try...finally?   The ZipFile is IDisposable.  Do you call ZipFile.Dispose()?  You need to, when you're done. Look at any example - it will show how to do it. 

From time to time there are bugs uncovered in the library.  But I don't recall anything like this.  I run lots and lots of tests, every  time I post a release, and I never get a "ask for a password" when there was no password used.  

The first thing I would do, if I were you, is tighten up that code, and do a little more research on just when it asks for a password, and when your zip opener doesn't.  Narrow it down.

I'm glad to help in any way. If you can show me code that reliably produces a broken zip file, I am definitely interested in that.

-Cheeso

 

Read the full discussion online.

To add a post to this discussion, reply to this email (DotNetZip@discussions.codeplex.com)

To start a new discussion for this project, email DotNetZip@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Coordinator
Oct 29, 2009 at 2:47 AM
Edited Oct 29, 2009 at 2:50 AM

Sounds great.

Oh, another thing I noticed.  In your code, you specify the name for the zipfile twice, and differently.   You specify when instantiating the ZipFile object, and also when calling Save().  That really isn't necessary.  Thinking about it now, there are 300+ tests, but I don't believe I have any tests that do *that.    It just may be that it produces a screwy zip file, sometimes.  I'll add some tests and investigate.   But in the meantime, what I would suggest is that you specify the zipfile name, in one place or the other, but not both.  Either in the constructor, or in the Save() call, but not both. 

Something like this:

// create a ZipFile object, with no backing store, just yet
using (ZipFile zipfile = new ZipFile())  // <<-- notice: no file name !
{
    // add the sourceFolderContents to the zip file
    zipfile.AddDirectory(sourceFolder,subfoldername);

    // now, save file in the destination folder
    var pathToZip = System.IO.Path.Combine(destinationFolder, zipFileName);
    zipfile.Save(pathToZip);
}

Oct 30, 2009 at 1:32 AM
I ran this code in an asp.net website and kept getting the same prompt for a password when I upzipped it.

 var zipFileName = DateTime.Now.ToFileTime() + "test.zip";
            var destinationFolder = @"F:\Documents and Settings\Administrator\Desktop\ZipTest\ZipTest\ZipTest\zipto";
            var pathToZip = System.IO.Path.Combine(destinationFolder, zipFileName);
            var sourceFolder = @"F:\Documents and Settings\Administrator\Desktop\hic";

            using (ZipFile zipFile = new ZipFile(pathToZip))
            {
                zipFile.AddDirectory(sourceFolder);
                zipFile.Save();

            }     

I then decided to just make a simple console app with the same code above.  Now when I unzip it, it doesn't ask for a password.  That means DotNetZip isn't causing the error.  Something to do with asp.net, IIS, or some other configuration.

Thanks for your help.

On Wed, Oct 28, 2009 at 10:47 PM, Cheeso <notifications@codeplex.com> wrote:

From: Cheeso

Sounds great.

Oh, another thing I noticed.  In your code, you specify the zipfile twice, and differently.   You specify when instantiating the ZipFile object, and also when calling Save().  That really isn't necessary.  Thinking about it now, I don't believe I have any tests that do *that*, and it just may be that it produces a screwy zip file, sometimes.  What I would suggest is that you specify the zipfile name, in one place or the other, but not both.  Either in the constructor, or in the Save() call, but not both. 

Something like this:

// create a ZipFile object, with no backing store, just yet
using (ZipFile zipfile = new ZipFile())  // <<-- notice: no file name !
{
    // add the sourceFolderContents to the zip file
    zipfile.AddDirectory(sourceFolder,subfoldername);

    // now, save file in the destination folder
    var pathToZip = System.IO.Path.Combine(destinationFolder, zipFileName);
    zipfile.Save(pathToZip);
}

Read the full discussion online.

To add a post to this discussion, reply to this email (DotNetZip@discussions.codeplex.com)

To start a new discussion for this project, email DotNetZip@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Oct 30, 2009 at 3:01 AM
Would the names of the files getting zipped affect DotNetZip?

I changed the code to rename all the files to short file names prior to zipping.  After DotNetZip renames and zips, I extract it with windows zip, and it doesn't prompt me for a password.

FYI - I am zipping up a large number of files with long file names

Here's a sample of the original files before zipping:
FileSize    FileName
3,910,100 Copy (17) of 02_iso100_14mm.jpg
6,620,910 Copy (17) of 05_iso100_14mm.jpg
6,830,197 Copy (17) of 15_megapixels.jpg
8,163,360 Copy (17) of church.jpg
4,297,120 Copy (17) of D3_1118_14-24_24mm_f2.8.JPG
3,910,100 Copy (18) of 02_iso100_14mm.jpg
6,620,910 Copy (18) of 05_iso100_14mm.jpg
6,830,197 Copy (18) of 15_megapixels.jpg
8,163,360 Copy (18) of church.jpg
4,297,120 Copy (18) of D3_1118_14-24_24mm_f2.8.JPG
3,910,100 Copy (19) of 02_iso100_14mm.jpg
6,620,910 Copy (19) of 05_iso100_14mm.jpg
6,830,197 Copy (19) of 15_megapixels.jpg
8,163,360 Copy (19) of church.jpg
4,297,120 Copy (19) of D3_1118_14-24_24mm_f2.8.JPG
3,910,100 Copy (2) of 02_iso100_14mm.jpg
6,620,910 Copy (2) of 05_iso100_14mm.jpg
6,830,197 Copy (2) of 15_megapixels.jpg
8,163,360 Copy (2) of church.jpg
3,910,100 Copy (2) of Copy of 02_iso100_14mm.jpg
6,620,910 Copy (2) of Copy of 05_iso100_14mm.jpg
6,830,197 Copy (2) of Copy of 15_megapixels.jpg
8,163,360 Copy (2) of Copy of church.jpg
3,910,100 Copy (2) of Copy of Copy of 02_iso100_14mm.jpg
6,620,910 Copy (2) of Copy of Copy of 05_iso100_14mm.jpg
6,830,197 Copy (2) of Copy of Copy of 15_megapixels.jpg
8,163,360 Copy (2) of Copy of Copy of church.jpg
3,910,100 Copy (2) of Copy of Copy of Copy of 02_iso100_14mm.jpg
6,620,910 Copy (2) of Copy of Copy of Copy of 05_iso100_14mm.jpg
6,830,197 Copy (2) of Copy of Copy of Copy of 15_megapixels.jpg
8,163,360 Copy (2) of Copy of Copy of Copy of church.jpg
3,910,100 Copy (2) of Copy of Copy of Copy of Copy of 02_iso100_14mm.jpg
6,620,910 Copy (2) of Copy of Copy of Copy of Copy of 05_iso100_14mm.jpg
3,764,006 Copy (2) of Copy of Copy of Copy of Copy of 10_iso100_14mm.jpg
6,830,197 Copy (2) of Copy of Copy of Copy of Copy of 15_megapixels.jpg
8,163,360 Copy (2) of Copy of Copy of Copy of Copy of church.jpg
4,297,120 Copy (2) of Copy of Copy of Copy of Copy of D3_1118_14-24_24mm_f2.8.JPG
4,297,120 Copy (2) of Copy of Copy of Copy of D3_1118_14-24_24mm_f2.8.JPG
4,297,120 Copy (2) of Copy of Copy of D3_1118_14-24_24mm_f2.8.JPG
4,297,120 Copy (2) of Copy of D3_1118_14-24_24mm_f2.8.JPG
4,297,120 Copy (2) of D3_1118_14-24_24mm_f2.8.JPG
3,910,100 Copy (20) of 02_iso100_14mm.jpg
6,620,910 Copy (20) of 05_iso100_14mm.jpg
6,830,197 Copy (20) of 15_megapixels.jpg
8,163,360 Copy (20) of church.jpg
4,297,120 Copy (20) of D3_1118_14-24_24mm_f2.8.JPG
3,910,100 Copy (21) of 02_iso100_14mm.jpg
6,620,910 Copy (21) of 05_iso100_14mm.jpg
6,830,197 Copy (21) of 15_megapixels.jpg
8,163,360 Copy (21) of church.jpg
4,297,120 Copy (21) of D3_1118_14-24_24mm_f2.8.JPG
3,910,100 Copy (22) of 02_iso100_14mm.jpg
6,620,910 Copy (22) of 05_iso100_14mm.jpg
6,830,197 Copy (22) of 15_megapixels.jpg
8,163,360 Copy (22) of church.jpg
4,297,120 Copy (22) of D3_1118_14-24_24mm_f2.8.JPG
3,910,100 Copy (23) of 02_iso100_14mm.jpg
6,620,910 Copy (23) of 05_iso100_14mm.jpg
6,830,197 Copy (23) of 15_megapixels.jpg
8,163,360 Copy (23) of church.jpg
4,297,120 Copy (23) of D3_1118_14-24_24mm_f2.8.JPG
3,910,100 Copy (24) of 02_iso100_14mm.jpg
6,620,910 Copy (24) of 05_iso100_14mm.jpg
6,830,197 Copy (24) of 15_megapixels.jpg
8,163,360 Copy (24) of church.jpg
4,297,120 Copy (24) of D3_1118_14-24_24mm_f2.8.JPG
3,910,100 Copy (25) of 02_iso100_14mm.jpg
6,620,910 Copy (25) of 05_iso100_14mm.jpg
6,830,197 Copy (25) of 15_megapixels.jpg
8,163,360 Copy (25) of church.jpg

On Thu, Oct 29, 2009 at 9:32 PM, bbolton <notifications@codeplex.com> wrote:

From: bbolton

I ran this code in an asp.net website and kept getting the same prompt for a password when I upzipped it.

 var zipFileName = DateTime.Now.ToFileTime() + "test.zip";
            var destinationFolder = @"F:\Documents and Settings\Administrator\Desktop\ZipTest\ZipTest\ZipTest\zipto";
            var pathToZip = System.IO.Path.Combine(destinationFolder, zipFileName);
            var sourceFolder = @"F:\Documents and Settings\Administrator\Desktop\hic";

            using (ZipFile zipFile = new ZipFile(pathToZip))
            {
                zipFile.AddDirectory(sourceFolder);
                zipFile.Save();

            }     

I then decided to just make a simple console app with the same code above.  Now when I unzip it, it doesn't ask for a password.  That means DotNetZip isn't causing the error.  Something to do with asp.net, IIS, or some other configuration.

Thanks for your help.

On Wed, Oct 28, 2009 at 10:47 PM, Cheeso <notifications@codeplex.com> wrote:

From: Cheeso

Sounds great.

Oh, another thing I noticed.  In your code, you specify the zipfile twice, and differently.   You specify when instantiating the ZipFile object, and also when calling Save().  That really isn't necessary.  Thinking about it now, I don't believe I have any tests that do *that*, and it just may be that it produces a screwy zip file, sometimes.  What I would suggest is that you specify the zipfile name, in one place or the other, but not both.  Either in the constructor, or in the Save() call, but not both. 

Something like this:

// create a ZipFile object, with no backing store, just yet
using (ZipFile zipfile = new ZipFile())  // <<-- notice: no file name !
{
    // add the sourceFolderContents to the zip file
    zipfile.AddDirectory(sourceFolder,subfoldername);

    // now, save file in the destination folder
    var pathToZip = System.IO.Path.Combine(destinationFolder, zipFileName);
    zipfile.Save(pathToZip);
}

Read the full discussion online.

To add a post to this discussion, reply to this email (DotNetZip@discussions.codeplex.com)

To start a new discussion for this project, email DotNetZip@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Read the full discussion online.

To add a post to this discussion, reply to this email (DotNetZip@discussions.codeplex.com)

To start a new discussion for this project, email DotNetZip@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Coordinator
Oct 30, 2009 at 9:15 AM

DotNetZip should be fine with any valid Windows filename.

Earlier you said it worked in a Console application , but not in ASP.NET.  Now you are suggesting the cause is the filenames.  Have you tested this?  what is the real answer?  does it work in ASP.NET or not? 

It sounds like you have some testing to do. If I were you,  I'd start with the very simple case, and then add complexity as you go.