If I have a large zip file and add a file into it, will Windows create a copy of the file and then delete the original, causing very large "write amplification", or will it just add to the file?

(Perhaps it matters if it's an SSD or HDD?)

  • Excellent question – Nifle Feb 24 at 9:14

Although the Zip file format was defined to allow fast appends without recopying the whole archive, I don't know of a Zip/7Zip program that does it.

The Zip archive contains an inner directory that allows direct access to any included item. The directory is stored at the end of the archive, and all items including the directory are identified by a header.

In principle, appending a new item to the archive can be done by appending it to the archive file, then appending a new directory. However, a computer failure before the new directory was completely written and flushed out to the disk, may leave the archive with rubbish at its end.

While in theory this can still be recovered by scanning from the end of the archive for the header of the last written directory, a program that just expects to find the directory at the end of the file will fail, announcing a corrupt archive.

I have tested appending a file to an archive for two Zip products and for 7Zip, querying the archive's disk address before and after the operation. I used for that the fsutil file queryextents command.

None of the three products has attempted to optimize the append operation. All three have recopied the entire archive when appending the new item.

My conclusion is that, while such an optimizing product may exist, it is best to test whether yours is one such. Without testing, the default assumption should be that the archive will be recopied.

| improve this answer | |
  • 1
    I've done some testing on this as well in the past and can confirm that every zip-tool I have ever tested does create a new zip with the combined content and then deletes to old zip and renames the new one. Some tools are more efficient than others though. 7zip just copies the compressed data from the original zip "as is" in the new file and then adds the extra file to it. While Explorer and WinRar always decompress the entire original zip and then re-compresses everything, which can take a lot longer. – Tonny Feb 21 at 9:54
  • 1
    @ispiro Same way as harrymc mentioned in his answer. Using fsutil to determine which disk-blocks are taken by the file. If it really appends to the oringal file the untouched part of the zip-file stays on the same blocks. If it does a copy you'll get new blocks for the entire file. – Tonny Feb 21 at 9:58
  • @Tonny Thank you very much! (I really didn't understand what that meant. Thanks for explaining.) One test I did didn't move the whole file. Maybe it's dependent on whether Windows thinks it can further compress it. – ispiro Feb 23 at 12:58
  • I right-clicked a PDF, Send to, Compressed (zipped) folder, noted the creation time. I then dragged a different PDF to the new zip file & it didn't change the create time. I confirmed both PDF files were in the ZIP file. So it doesn't APPEAR to create a new file, but I'm aware it could trick me into believing that, is that the case? I don't doubt it unzips files to a temp directory, but I guess that's a different question/element. This is Win10 v1607 x64 using the built-in ZIP – gregg Feb 25 at 22:28
  • 1
    @gregg: Create time is easily modified by API. It's logical for it to be conserved. – harrymc Feb 26 at 7:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.