It seems, from my experience and from this thread, that Opus reports 'access is denied', and prompts for elevation, when the user tries to perform an operation (or one of some range of operations) upon a file or directory. Would it not be better were Opus to report - in that case - that the file is in use, and not prompt for (useless) elevation?
It's not Opus doing that, it's Windows.
Thanks for the reply, Leo. But just what is happening? Perhaps (1) Windows supplies error data that Opus decodes. If so, could Opus decode it better, so as to distinguish needs-elevation from file-locked? Or else (2) Windows generates the whole error box. In that case, can you catch the error in some way, i.e., get Opus to handle the error - and in such a way as to make the aforementioned distinction? But perhaps I misunderstand.
Windows returns the same error code for "access denied due to user permissions" and "access denied due to file in use". There's no way to distinguish them, they're literally the same error code.
Wow: that's pretty desperate on the part of Windows. Hold on, though: I've seen various program other than Opus report that a file was in use and so could not be accessed.
Yes, indeed. Sometimes, if I try to remove a file, DOpus shows that a particular program blocks it:
How does it know what program blocks it?
That dialog is from Windows, not Opus. You’re deleting to the Recycle Bin there, which is handled by Windows, including the UI in the screenshot.
We can tell sometimes which program has a file in use, but the API for that isn’t very reliable and often returns incomplete or incorrect results. It’s also slow, and would mean extra delays any time there was an error.
Thank you for the explanation.
It’s also slow, and would mean extra delays any time there was an error.
Yes, as I made ShowWhatProcessLocksFile tool, it is indeed unbelievable that there is no API in Windows to ask "what locks this file". It is super easy on Linux. But on Windows, it is just impossible. You have to write a kernel driver for that.
The problem is that this functionality is also necessary for installers, as they need to inform you if some app is preventing a program from being uninstalled.
Technically, there is an undocumented Windows API that can be used, but it has a serious bug - it deadlocks without any way to recover. Microsoft never fixed it. And it is literally from the beginning of Windows. It has never worked. That is the exceptional backward compatibility 
1 Like