Directory Opus corrupting WinZip encrypted file

Bottom Line Up Front: Any actions taken by Opus which result in a zip file containing a mix of some files being encrypted and others not being encrypted cause the WinZip file to become corrupted and FAIL when trying to re-access them within WinZip itself.

This is more of a note to the developers requesting feedback on the status of this situation rather than a request for help. The only topics I see remotely close to this topic are from 5 years ago. You may or may not be aware of an incompatibility between Opus and WinZip encrypted ZIP files.

My software:

  • Windows 11
  • Directory Opus 12, Ver 12.30, Build 8360, 64bit
  • WinZip 27 Pro, Ver 76.2, Build 15241, 64bit

The Issue:

  • Upon entering the password and opening a WinZip encrypted zip file within DO:
    o Browsing, Viewing and Copying from the files contained within work well
    o Thumbnails View does not properly represent the files within
    o ANY files added to the zip file (via Opus) are not encrypted and causes CORRUPTION
    o ANY file rename actions on a file within causes it to become decrypted and causes CORRUPTION

CORRUPTION:

  • Any actions taken by Opus which result in a zip file containing a mix of some files being encrypted and others not being encrypted cause WinZip to FAIL when trying to access the encrypted files within.
  • Example: WinZip creates an encrypted zip file (call it DIR01) containing the following files within: file01, file02 and file03.
    o DIR01 is opened in Opus
    o From within Opus the user renames file01 to file00 and adds file04 to the collection
    o DIR01.zip now contains file00 (not encrypted), file02 (encrypted), file03 (encrypted) and file04 (not encrypted)
    o From this point on, opening the DIR01.zip in WinZip or via the "Unzip to here" WinZip context menu item, this happens:
     file00 and file04 can be extracted but file02 and file03 FAIL EXTRACTION
     "Central and local directory mismatch for file "file_name" (crc-32 - local: hex_code hex central: 0 hex errors are encountered
     WinZip itself cannot add to, rename nor encrypt files within DIR01.zip
  • Interestingly: Opus can still work with these “corrupted” files! Opus can continue to add and rename files to the zip file and work with it without fail.
  • The ONLY apparent work around for these corrupted files, that I know of so far, is to use Opus to reopen the zip file and rename the encrypted files within - causing them to become un-encrypted. At this point they can now be extracted in WinZip and renamed back to the original names as appropriate.
  • One other way would be to extract the zip file with Opus, then rebuild and encrypt it in WinZip.
  • Neither these “solutions” is desirable for many reasons. Imagine a customer working with an encrypted folder containing numerous subfolders and 1000s of files. These files now must be un-encrypted before being re-encrypted and possibly leaving traces of themselves behind. Loss of productivity is another significant factor.

SOLUTIONS:

  • There may be programming or WinZip licensing restrictions standing in the way of a fix, but in my own humble opinion the solution I would like to see is:
  1. Get with WinZip and see if they have any plans to develop/incorporate a “mixed-mode” (encrypted mixed with non-encrypted) zip file standard. Their program does not appear to allow the creation of these.
  2. Build the encryption piece into Opus and force encryption on any files copied into a WinZip encrypted zip file seamlessly, adopting the same encryption password.
  3. Cause renamed encrypted files (which appear to consist of copying as new name and deletion of “renamed” file) and force these files to also remain or be encrypted.
  4. Address the hex code corruption that WinZip doesn’t like.
  5. Allow the proper display of thumbnails ONLY after the password has been entered in Opus for that session.

Thank you,
Ed Williams

This doesn't happen with encrypted Zip archives made by Opus, but I know WinZip have done some proprietary extensions to Zip in the past, so it could be a case of that and us not handling them correctly.

Could you send us a small sample Zip file made with WinZip that can be used to reproduce what you describe? (Even better, one from before the problem happens, and a second copy of the result of the problem, in case we aren't able to trigger the same problem for some reason. May help us work out which options or actions are involved if it doesn't happen for us.)

Sure! Will put something together shortly.

1 Like

Leo,
I've finished researching and have 11 files to send. Unfortunately I am only allowed to send 5 at a time. I'll be selective and send what I can. Please review the zip files contained within "Opus-WinZip Compatibility Research.zip" for a full breakdown on this topic. You may also request any of the other files I've referenced and may not have been able to upload.

Opus-WinZip Compatibility Research.zip (26.4 KB)
OpusEncrypted.zip (6.5 MB)
OpusEncryptedOpusAddedTrailer.zip (7.5 MB)
WinZipEncrypted.zip (6.5 MB)
WinZipEncryptedOpusAddedTrailer.zip (7.5 MB)

OpusEncryptedOpusAddedTrailerWinZipReencrypted.zip (7.5 MB)
OpusEncryptedOpusRenamedArtworkToHills.zip (6.5 MB)
OpusEncryptedWinZipAddedTrailer.zip (7.5 MB)
OpusEncryptedWinZipRenamedArtworkToHills.zip (6.5 MB)

OpusEncryptedOpusAddedTrailerWinZipReencryptedOpusAddedBackground.zip (8.5 MB)
WinZipEncryptedOpusRenamedArtworkToHills.zip (6.5 MB)

What is the password(s) for the zips?

Sorry :smiley: its 1234abcd