This project is read-only.

AddDirectory stops when password = null

Oct 17, 2011 at 2:30 PM
Edited Oct 17, 2011 at 3:13 PM


when I use ZipFile.AddDirectory with zip.Encryption = None and zip.Password = null, adding stops on some source directories. I have 6 directories in a network share, 4 of them are ok, on 2 the adding process stops in the middle of processing. Interestingly, AddDirectory returns ok although the written .tmp file is far too small, but Save never returns and the program stops (it doesn't crash, it simply doesn't continue even if you wait for hours). With a valid password set, everything is o.k.

Target is another network share. The same happens whe I use DotNetZip Tool V1.9.1.8 (the graphical tool provided in the download), so I'm sure it isn't my program.

This is my code (slightly simplified for readability, ini file settings and console messages left out):

      using (var zip = new ZipFile())
            zip.CompressionMethod = CompressionMethod.Deflate;
            zip.CompressionLevel = CompressionLevel.BestCompression;
            zip.Strategy = CompressionStrategy.Default;
            zip.Encryption = EncryptionAlgorithm.None;
            zip.Password = "Password";
            zip.Comment = "some comment";
            zip.Name = String.Format("{0}\\{1}.{2}", tpath, i.Name, "zip");
            string sname = String.Format("{0}\\{1}", spath, i.Name);


No effect, if I exchange the Encryption and password lines; if  I set zip.Password = null, 4 of 6 directories are ok, 2 not. AddDirectory finishes, but leaves a too small tmp file, save never returns.

There is no visible difference between the directories, working ones are even bigger than the failing and hold bigger files, rights etc. etc. are all equal ...





Oct 18, 2011 at 8:47 AM

I  did some further investigation to the problem and I think I can tell now what causes the stops: Affected are only .CSV files. These contain (necessarily as required by the basic application) a variety of escape characters such as %s, %f, %D, \C, \R, \e etc. Probably one or more of these characters are interpreted as control characters when output unchanged and cause the program to stop at the actual file. When encoded with a password, they are changed to something else and the program runs o.k. Can't tell which character exactly it is, this would be too much work for now. Strangely, some of the csv files (with these characters) work while others don't.



Oct 18, 2011 at 12:35 PM

After all, I found a workaround: zip.ParallelDeflateThreshold = -1 did the trick. Definitely a bug ...

Nov 24, 2011 at 7:12 AM

Dear kpfisher,


I struggled with the same problem and - as I am new to powershell and .Net I searched where I made a mistake. It took me more than a day 'til I found your post.


Thanks a lot!

I want to add folders containing the compilation and it used to hang after some minutes of working.

What would you think is the fastest way to get things done? Setting ParallelDeflateTreshold?


Nov 26, 2011 at 4:21 PM

Dear PSBeginner,

I think I don't understand quite well what you want to do. All I can say is that zip.ParallelDeflateThreshold = -1 prevent the lib from hanging on files that contain special characters as described above. Of course compiled files may eventually contain such characters also, so I think it is best to deactivate ParallelDeflateThreshold.