Can't unzip from network drive to program files subfolder

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:

  1. 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).
  2. Use DO's ability to view inside zip archives to view the contents of the plugin archives I want to install.
  3. 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.

Any ideas how to fix this? Thanks!

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).

Mapped drive letters sometimes don't work through elevation as well, since the elevated context may use different drives.

If you use the UNC path \\server\share\... instead of a mapped letter, that may make it work.

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.

Very interesting. This did indeed work. I find that bizarre I have to say. Thanks!

One of many reasons to never map network drive letters. :slight_smile: They cause problems and aren’t really that useful.

Alberto Martinez answer describes why the mapped network drive is not accessible.

Here is registry fix to solve the problem:

  • Open regedit and go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
  • Add a new DWORD (32-bit) Value named EnableLinkedConnections.
  • Adjust the value to 1 (or 00000001).

Exit regedit and restart the computer.

Got too much software that won't let me specify a UNC network path to do away with drive letters. Unfortunate reality, that.

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!