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:
- 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.
- 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.
- 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.
- Address the hex code corruption that WinZip doesn’t like.
- Allow the proper display of thumbnails ONLY after the password has been entered in Opus for that session.
Thank you,
Ed Williams
its 1234abcd