[ { "Id": "160410", "ThreadId": "48080", "Html": "Im adding a large psd file sized 70 486 013 to an archive.
\r\nOpening the resulting zip with winrar shows the packed size of the file is 53 896 916. However the zip file itself is 161 691 180.
\r\nAfter running Repair Archive in winrar the file size is reduced to 53 897 060. 
\r\nWhat am I missing?
\r\n
\r\n'Create Archive at ArchiveFullPath 
\r\n    Archive = New ZipFile(ArchiveFullPath) 
\r\n    Archive.TempFileFolder = "C:\\Temp"
\r\n
\r\n'Add files from Directory pointed by DirectoryInfo Di
\r\n    Dim Files() as FileInfo 
\r\n    Files = Di.GetFiles() 
\r\n
\r\n    For i As Integer = 0 To Files.Length - 1 
\r\n        Archive.AddFile(Files(i).FullName, "Assets") 
\r\n    Next
\r\n 
\r\n    Archive.Save() \r\n", "PostedDate": "2009-02-21T04:14:59.763-08:00", "UserRole": null, "MarkedAsAnswerDate": null }, { "Id": "160464", "ThreadId": "48080", "Html": "Hmmm, interesting puzzle.
\r\nSome questions:
\r\nFirst, What version of the DotNetZip library are you using?  In v1.6 and prior releases, the size of the "compressed data" could actually be larger than the data itself.  This was the result of well-known anomalous compression behavior in System.IO.Compression.DeflateStream. (it's been raised as a bug with Microsoft but there's no fix yet).   In v1.7, DotNetZip includes a different managed DeflateStream class, based on zlib, which never inflates the data.  If you are using v1.6 I advise that you migrate to v1.7 ASAP, and retry. 
\r\n
\r\nIf you are using v1.7, can you give me a list of the entries in the zip file, the output of  DotNetZip's "unzip -l" tool?
\r\nTell you what:  give me the output of "unzip -l" both BEFORE and AFTER you run the archive through winrar.
\r\n
\r\nI would also like to know the other options you used on the zip file:
\r\n the CompressionLevel setting
\r\n the encryption if any
\r\n 
\r\nWhat's a PSD file? \r\n", "PostedDate": "2009-02-21T10:08:59.8-08:00", "UserRole": null, "MarkedAsAnswerDate": null }, { "Id": "160613", "ThreadId": "48080", "Html": "

A psd file is a PhotoShop work image including all the layers etc.

\r\n

I'm using ver 1.7 with default settings (maybe this is the problem, do I need to set a compression level) and here is the output from unzip utility. For your information I get the same results with large tiff files. I'm working with apps for print shops and usally handeling very highres images. This is the outut from the requsted tests. For simlicity the directory path were removed from the result:

\r\n>unzip -l Test.zip
\r\nZipfile: Test.zip
\r\n
\r\nModified Size Ratio Packed pw? CRC Filename
\r\n--------------------------------------------------------------------------------
\r\n2008-09-26 13:59:00 70486013 24% 53896916 N 0840087C Assets/Dalia & Isak.psd
\r\n
\r\n>unzip -l rebuilt.Test.zip
\r\nZipfile: rebuilt.Test.zip
\r\n
\r\nModified Size Ratio Packed pw? CRC Filename
\r\n--------------------------------------------------------------------------------
\r\n2008-09-26 13:59:00 70486013 24% 53896916 N 0840087C Assets/Dalia & Isak.psd
\r\n
\r\n>Dir *.zip
\r\nVolymen i enhet C har ingen etikett.
\r\nVolymens serienummer är CC5A-1E96
\r\n
\r\nInnehåll i katalogen 
\r\n2009-02-21 13:02 53 897 060 rebuilt.Test.zip
\r\n2009-02-21 12:56 161 691 180 Test.zip 
\r\n\r\n", "PostedDate": "2009-02-22T06:03:03.39-08:00", "UserRole": null, "MarkedAsAnswerDate": null }, { "Id": "160632", "ThreadId": "48080", "Html": "hmmm ok thanks. I will have a look.
\r\nYou don't need to set a compression level different than the default. Normally the default is very effective.
\r\n", "PostedDate": "2009-02-22T09:27:29.463-08:00", "UserRole": null, "MarkedAsAnswerDate": null }, { "Id": "160638", "ThreadId": "48080", "Html": "what version, specifically, of v1.7 ? 
\r\nCan you print out the ZipFile.LibraryVersion property? \r\n", "PostedDate": "2009-02-22T09:49:14.553-08:00", "UserRole": null, "MarkedAsAnswerDate": null }, { "Id": "160647", "ThreadId": "48080", "Html": "I tried reproducing this behavior here using PSD files and other large binary files, running it through the code you supplied.  I could not reproduce the problem. I am using the latest release of DotNetZip.
\r\n
\r\nIt's odd to me that unzip -l would report a small, apparently correct "compressed size" value, but yet the actual zip file is so large.  The only way this could happen is if there is a large amount of rubbish data in that zip archive.
\r\nIt's possible there was a double-write problem in earlier v1.7 versions of DotNetZip, where zip content would be written twice to the file, and then orphaned. In theory, this could produce the size discrepancy you are seeing.  I remember there was a problem with the re-compress logic in pre-final versions of v1.7 - it was re-reading files and re-compressing unconditionally - but I don't remember a size discrepancy as a symptom of that problem.  Just because i don't remember it doesn't mean it didn't happen, though.  This problem was fixed before the final release of v1.7 (which was v1.7.2.4).
\r\n
\r\nKeep in mind that "v1.7" is not enough to completely describe the assembly you are using.  There were multiple step improvements along the way to a final release of v1.7 (and even some minor improvements after).  I'd like to verify the exact version of the library (you'll get that with ZipFile.LibraryVersion) and I'd like you to try using the latest v1.7 release, which is v1.7.2.7.  
\r\n
\r\n", "PostedDate": "2009-02-22T10:32:05.207-08:00", "UserRole": null, "MarkedAsAnswerDate": null }, { "Id": "160679", "ThreadId": "48080", "Html": "I've checked the version wich is 1.7.2.7.
\r\nIf it can be of help I've made a test zip file avaliable at http://www.vilundate.se/dotnetzip/Test.zip 
\r\nThank's for your concern
\r\n", "PostedDate": "2009-02-22T12:22:50.483-08:00", "UserRole": null, "MarkedAsAnswerDate": null }, { "Id": "160687", "ThreadId": "48080", "Html": "Ok I am copying that file now.
\r\nAny chance you could give me one of the psd files that leads to the problem? \r\n", "PostedDate": "2009-02-22T12:47:57.957-08:00", "UserRole": null, "MarkedAsAnswerDate": null }, { "Id": "160712", "ThreadId": "48080", "Html": "

Hmmm, very curious.  I got the zip file.  Obviously it is much larger than it needs to be. I unpacked it and got the 70mb PSD file.  I then zipped that up with the VB code that you provided. And the result was a zip file of 161mb.  So I immediately reproduced the problem you reported. I think.

\r\n

After seeing the unexpectedly large zip file, I tried it again, more than 10 times, using the same code and in each case, I got a zip file that was 53mb. 

\r\n

At this point I am questioning whether I really saw the first result.

\r\n

I downloaded the file again, and tried again, and still, I was not able to reproduce the anomalous behavior. Is it reproducible on your machine?

\r\n

I saw what you reported, I think, just once, but now I cannot get it to happen again. 

\r\n", "PostedDate": "2009-02-22T14:49:01.02-08:00", "UserRole": null, "MarkedAsAnswerDate": null }, { "Id": "160746", "ThreadId": "48080", "Html": "Very odd.  The zipfile you sent to me contains 3 copies of the zip, concatenated to each other.  It is as if you created the zipfile, then did a
\r\n  copy /b  zipfile.zip+zipfile.zip+zipfile.zip  Test.zip
\r\n
\r\nI don't understand how this could happen, using just the DotNetZip API.  So far, I cannot get it to happen here.
\r\nIs it repeatable at your place? \r\n", "PostedDate": "2009-02-22T16:29:49.403-08:00", "UserRole": null, "MarkedAsAnswerDate": null } ]