Don't know if this has been reported before, but here goes:
Steps to reproduce: Go to techmoan.com/blog/2013/8/31/ ... creen.html)
Open in Directory Opus and it shows 0 files.
Open in Windows Explorer and it shows 3 video files.
Version info:
Directory Opus Pro 10.5.2.0 (4913) x64
OS 6.1 (B:7601 P:2 T:1) SP 1.0 "Service Pack 1"
I have no clue what they used to compress the files and it's the first time I've run into this issue. Tried on two computers as well.
The zip is not valid, and Opus is rejecting the files within it in case they are trying to exploit the zip format.
It has the same problem as the archive mentioned here: Re: Problematic ZIP archive, including the phenomenon that when you rename the archive, a directory inside the archive gets renamed as well (depending on which tools you use to view the archive).
Okay, I kind of understand that. This is a ZIP file created by DropBox so I would think that maybe Opus is being a little too cautious here then. Especially if Windows opens it without an issue. Personally, I hate it when software thinks it knows better than me 
... Without trying to be arrogant, most of the time it doesn't.
Well, I wouldn't call an attempt to prevent a potential security exploit a simple case of software erroneously thinking it knows better than you. And just because an archive file was created by Dropbox doesn't mean it's safe, and no app has any way of knowing the origin of such a file anyway. Citing that Windows Explorer happily opens the file isn't really credible justification that other apps should do the same, or that Opus is ~wrong and Microsoft is ~right. If that argument held water, then we wouldn't need third-party security software at all right 
?
Maybe GPsoft could in fact do something to better differentiate a simple case of an invalid file like this from something more sinister that might be attempting to exploit a vulnerability... I don't know. But really, there are established specs for things like archive file formats for good reasons. I'm not attacking your opinion, but my own is that the thing that would make the most sense would not be to ask GPsoft to compromise it's approach to security, but for Dropbox to fix the problem at the source by adhering to an established spec.
FWIW: PowerArchiver also fails to 'open' the file. It gets stuck indefinitely on "Reading folder". Though strangely, PA can perform a context menu initiated 'extract' of the contents...
...my 2 cents...
I would never, ever, ever, ever, ever say Microsoft does the right thing or that they should be trusted to do the right thing... I worked for them for 18 years. The insane are running the asylum
I was mostly just pointing out that it did contain files and was confusing to me why Opus would not show anything, as if it was just an empty zip file, while another program (which happened to be Windows) showed actual files. What I read and interpreted in the response was "We're doing it for your own safety", which is a sore spot for me. (I admit, I could have interpreted it wrong)
I think the proper behavior would be to somehow notify the user that it's having a problem opening the file. Not show it as being empty.
If my C# program can indicate the file has an invalid local signature header (In this case, -1008965968), instead of 67324752 then Opus should say something like that to the user instead of an empty folder.
I will drop off a note to DropBox and let them know of the issue I'm having with their zip files and do some more testing with my own DropBox account to see if it shares the same problem.
In the meantime, I would just like to make a suggestion that Opus notify the user that it's having problems with a zip file, not show it as having 0 files.
btw: I've been using Opus for over 5 years and this is the first unexplainable thing I've run in to and had any complaints about... not a bad track record 
Makes sense to me...