dl.dropbox.com/u/62209281/Keys%2 ... savsav.zip
7-zip and other archivers can open it without problems, but for DOpus the archive appears as empty. Both when it is entered and when unpacked.
Directory Opus Pro 10.5.0.6 (4835) x64
OS 6.2 (B:9200 P:2 T:1) SP 0.0
I can't help but I can confirm that it displays as empty for me also.
More to the point, Bills full mp3 collection can be found here if you're interested... http://www.hourofthetime.com/wordpresstest/?page_id=7576
RIP Bill.
Starnge... what release are you on blueroly? Still on 10.5.0.5 here... and both opening as a folder AND extracting (copy extract=sub) show the same as PowerArchiver does == 66.4kb of data.
So, unless something broke in 10.5.0.6 - I can only think that something in Opus built-in ZIP support is disabled or something weird? But two of you having the same problem seems awefully odd. The md5 on the zip as I downloaded it from the link is:
5c3dd07d2abd6ff0211fee3f7211e2bc *Keys Ariva 23.03.13. savsav.zip
Shows as empty for me too. I'm on 10.5.0.6 so maybe that is the link.
Regards, AB
Oh dear, I screwed up. The archive was empty for me. I looked up the wrong archive so ignore the Bill comments 
The archive is 8.52Kb (5c3dd07d2abd6ff0211fee3f7211e2bc) for me. I'm running 10.5.0.6...
I think Opus is rejecting the archive because it has some paths that look illegal inside of it. (In some cases we reject such paths in case they are trying to exploit the zip format to cause crashes or worse, although it can also obviously be due to a bug in whatever created the zip as well.)
Both Opus's internal zip code (when the file has a normal .zip extension) and the archives plugin (if you rename it to .zipx) reject the file, and I suspect the reason is the same in both cases.
If you open the zip using 7-Zip, you'll see it has an extra folder in it which is always called the same name as the zip file itself. Rename the zip file and then open it in 7-Zip again, and that extra folder has been renamed again. That suggests the zip file has an entry inside of it which has a null path or which has a path like ".." or similar, which it should not have.
Aha, thanks Leo... and sure enough, after upgrading to 10.5.0.6 - I also now get the 'empty' archive result as well... I guess you guys tightened the code in this area for this beta beyond just the UTF related stuff in the change notes.