I stumbled across something odd which is best described by means of a couple of screen grabs. I have two active network shares mapped as X: and Z: and X: is the active folder in the first screen grab. Both drives show in the tree, but only Z: is shown in "other drives" which is generated by the command..
Refreshing the display did not help, however at some point later, X: did show up in the "other drives" display but with a leading slash missing as shown.
Can you think of anything unusual about the setup which might help us reproduce what you are seeing?
What type of device and version of Windows (if applicable) is hosting the two shares?
If you exit (via File > Exit Directory Opus) and restart Opus, is the backslash or drive itself missing from the menu again?
How does Explorer show the drive?
The machine where the screen grabs were taken is a Windows 8 desktop. The network PC is a Lenovo T410 laptop, also running Windows 8. Both PCs habitually run a few portable background utilities... Autohotkey, Clipmate, Everything, and Listary.
I tried several Opus restarts and a couple of desktop reboots earlier today. Results were not uniformly consistent but every time one or both of the reported symptoms presented. However, when I tried again 5 mins ago after a break of a couple of hours, everything behaved normally.
As time permits, I'll see if I can pin down the root cause. The Windows 8 / Windows 8 environment is my weekend setup. During the week, a locked down Windows 7 (work) boot disk goes into the Lenovo and network shares are blocked. To be continued......
I have managed to recreate in a Windows 7 environment, linking from a W7 virtual machine to admin shares on a top level W7 system.
Whilst it makes no sense, I suspect that the missing slash seen in the first screen grab below has to do with the fact that the user command that creates the shares (second screen grab) specifies \T410 for the first share and \t410 for the second share - the result of a typo on my behalf. I repeated the test using a modified user command where both servers are defined with an upper case T, and both shares then showed correctly with two slashes.
I can also report that when the user command is executed after booting the VM from cold, the first share (e$) appears immediately under Computer in the lister whereas the second share (c$) does not appear until I click to expand Computer in the folder tree or click to produce the drop down shown in screen grab #1.
Everything looks normal in the Explorer view shown in the third screen grab.
Portable Autohotkey, Clipmate, Everything, and Listary appear to play no part in any of this. The same behaviour manifests with or without these applications running on the VM.
I just tried with both shares mapped with a lower case "t". As in..
net use x: /d
net use x: \\t410\e$
net use z: /d
net use z: \\t410\c$
As reported above, when the user command is executed after booting the VM from cold, the first share (e$) appears immediately under Computer in the lister whereas the second share (c$) does not appear until I click to expand Computer in the folder tree or click to produce the drop down. The drop down now shows both shares with a single slash.
Ah, the \t must be looking like a tab character to some code. We should be able to fix that. Thanks!
That has been fixed for the next update.