This is a weird one, but it's 100% reproducible. I use JPSoft's "Take Command" application all the time, and it has a plugin architecture such that copying files into a "plugins" folder in its installation directory will load them at startup. I know said plugins are perfectly safe as I've been using them for years. And the way I usually install them with any new version is simplified by Directory Opus:
Open a dual-pane lister with my plugins installation folder on the left (viz., a network drive named T:\Setups\Utilities\JP Software\Plugins) and the program installation plugins folder on the right, (viz., C:\Program Files\JPSoft\TCMD33\plugins).
Use DO's ability to view inside zip archives to view the contents of the plugin archives I want to install.
Click the copy button to copy the files to the program installation plugins folder.
Since Windows added UAC, I have to click "Yes" to each UAC prompt, or I find I can simply click the "Admin" button in the Directory Opus toolbar before getting started to make copying files beneath the C:\Program Files folder a non-issue.
But when I tried doing that today with the latest version of Directory Opus after installing the new Take Command v33, I got a weird error every time I did the copy: "An error occurred copying: File not found. (ZIP Error 9)". I don't know why this is happening, and it happens only if I try to do that from the network drive I posted above. If I copy the zip archive to a folder on my local drives first instead (e.g., my downloads folder), then I can view the contents of the archive and copy them into the program installation plugins folder just fine.
Could be a rights issue.
Since you elevate Opus (Admin button), when accessing your network folder, you're no longer the user that used to mount the network drive.
EDIT : Do you open the zip file before getting elevated ? If not, maybe try to elevate before opening the zip because the issue could also be with some temporary folder used to unzip before copying (also related to user rights or something else).
Thanks for the thought, but I guess I'm confused: how can I still navigate mapped drives after elevating DO if I'm no longer the user who mounted the drive?! How can I do all the other things I can still do if I'm not still the user who mounted the drive?! I find that baffling.
Regardless of my confusion, it doesn't seem to matter whether I elevate before opening the zip file or not. I just closed DO, re-opened (in the hope of clearing any kind of temporary file caching or whatever), tried the test elevating before, and it didn't make any difference. I repeated that procedure elevating after opening the zip file as well, and it didn't make any difference.
Oh, not something I’ve run into in a long time with software. Moat things allow it since they don’t need to do anything special; the OS does all the work, the same as a path with a drive letter.
Thank you, @Konrad_Klar, for offering that link to an explanation and the procedure. I can confirm that solves the problem for me entirely. It also makes more sense of the problem, which is always a plus in my book. Cheers!