Hi,
\r\nI have the following code:
\r\n\r\n
static void Main(string[] args)
\r\n {
\r\n curPosX = Console.CursorLeft;
\r\n curPosY = Console.CursorTop;
\r\n using (ZipFile zipFile = new ZipFile())
\r\n {
\r\n zipFile.UseZip64WhenSaving = Zip64Option.Always;
\r\n zipFile.CompressionLevel = Ionic.Zlib.CompressionLevel.BestSpeed;
\r\n zipFile.SaveProgress += new EventHandler<SaveProgressEventArgs>(zipFile_SaveProgress);
\r\n zipFile.AddFile(@"C:\\TEMP\\speedtest_500MB.bin", "backup");
\r\n zipFile.Save(@"C:\\TEMP\\speedtest_500MB.zip");
\r\n }
\r\n }
static void zipFile_SaveProgress(object sender, SaveProgressEventArgs e)
\r\n {
\r\n if (e.TotalBytesToTransfer != 0)
\r\n {
\r\n Console.SetCursorPosition(curPosX, curPosY);
\r\n Console.WriteLine("Writing entry {0} of {1}, currently at {2}kb of {3}kb", e.EntriesSaved, e.EntriesTotal, e.BytesTransferred /1024, e.TotalBytesToTransfer / 1024);
\r\n }
\r\n }
This code takes a binary file of 500 MB in size and compresses it. But when the temporary file has been created for the first time, it immediately clears out the file again and starts all over again. Just after the second time the temporary file will be\r\n renamed to the speedtest_500MB.zip.
\r\nIs this normal behavior? Or am I doing something wrong?
\r\nRegards,
\r\nMarcel.
\r\n", "PostedDate": "2011-07-26T06:22:20.863-07:00", "UserRole": null, "MarkedAsAnswerDate": null }, { "Id": "647999", "ThreadId": "266593", "Html": "yes, the behavior you describe is expected. It's normal. (probably)
\r\nThere's a feature in the zip library that will store the file into the zip file \"uncompressed\", if \"compression\" increases the size of the file. This feature was added a long time ago, to combat the anomalous behavior of the builtin System.IO.Compression.DeflateStream, which, in some cases can increase the size of a file 40% or more. This happens with previously compressed data. Though DotNetZip no longer uses System.IO.Compression.DeflateStream - instead it uses its own managed ZLIB library for compression - and therefore the massive increases in size no longer are possible, the \"check for increase\" feature is still in there. It handles even small increases in size.
\r\nLooking at your code I see that you are using \"Bestspeed\" for the compression level. This can in some cases result in a slightly larger \"compressed\" file than the original \"uncompressed\" file. It will happen only when the original file is not really \"uncompressed\" - it will happen when it is in some compressed format. So the behavior you describe is normal if you are dealing with a file that is already compressed.
\r\nThere's currently no way to turn off the \"retry if the filesize increases\" feature.
\r\nI think if you raise the compression level to something better, you may avoid the problem. Conversely, if you know the file will not compress, you can specify CompressionLevel = None and the file will be stored directly, no attempt will be made to compress it.
\r\n", "PostedDate": "2011-07-26T15:07:49.873-07:00", "UserRole": null, "MarkedAsAnswerDate": null }, { "Id": "648177", "ThreadId": "266593", "Html": "Thanks!\r\n
\r\n\r\n\r\n\r\nFrom: Cheeso
\r\n\r\n\r\nyes, the behavior you describe is expected. It's normal. (probably)
\r\nThere's a feature in the zip library that will store the file into the zip file "uncompressed", if "compression" increases the size of the file. This feature was added a long time ago, to combat the anomalous behavior of the builtin System.IO.Compression.DeflateStream,\r\n which, in some cases can increase the size of a file 40% or more. This happens with previously compressed data. Though DotNetZip no longer uses System.IO.Compression.DeflateStream - instead it uses its own managed ZLIB library for compression - and therefore\r\n the massive increases in size no longer are possible, the "check for increase" feature is still in there. It handles even small increases in size.
\r\nLooking at your code I see that you are using "Bestspeed" for the compression level. This can in some cases result in a slightly larger "compressed" file than the original "uncompressed" file. It will happen only when the original file is not really "uncompressed"\r\n - it will happen when it is in some compressed format. So the behavior you describe is normal if you are dealing with a file that is already compressed.
\r\nThere's currently no way to turn off the "retry if the filesize increases" feature.
\r\nI think if you raise the compression level to something better, you may avoid the problem. Conversely, if you know the file will not compress, you can specify CompressionLevel = None and the file will be stored directly, no attempt will be made to compress\r\n it.
\r\n\r\n\r\n\r\nRead the \r\nfull discussion online.
\r\nTo add a post to this discussion, reply to this email (DotNetZip@discussions.codeplex.com)
\r\nTo start a new discussion for this project, email \r\nDotNetZip@discussions.codeplex.com
\r\nYou are receiving this email because you subscribed to this discussion on CodePlex. You can\r\n\r\nunsubscribe on CodePlex.com.
\r\nPlease note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com
\r\n
Ahh, right, random data will also be mostly incompressible.
\r\nCompression - all algorithms - work by replacing repeated patterns with smaller \"encodings\" . Random data won't exhibit those patterns and therefore won't be highly compressible.
", "PostedDate": "2011-07-27T05:36:25.65-07:00", "UserRole": null, "MarkedAsAnswerDate": null } ]