GP SoftwareTwitter
Opus FAQsManualCommandsObjects

Right-click on Symlink sub-folder/file hangs Opus+Explorer

Hello all,

I am experiencing a problem with Directory Opus and not sure if this is a general problem or something due to my particular system.

I have a Qnap NAS and I have created a symlink folder on a local drive to a share on the NAS, G:\Ymir_Media. The Qnap is joined to a domain and uses domain credentials to set file access to the share. Under the symlink you can navigate to folders such as Photos, Videos etc. Normal file operations work fine with this arrangement, copying, moving, deleting etc.

However ,when I right-click on a folder or file to pull up the right-click menu, to get to file properties for example, Directory Opus appears to hang. I say appears, because though it doesn't generate any error, it also never brings the menu up and the lister will no longer react to any other clicks. I have left these alone for a long time but nothing ever happens (i.e registering for this forum and writing this post). I can launch new listers to navigate my file structure, but these ones seem dead. I usually have to go into Task Manager and end task them.

I have no problems with the right-click menu on folders and files that are on local drives, and I do know how to troubleshoot dodgy menu entries by selectively removing them and then slowly enabling them again. Additionally I don't have any problems with accessing the right-click menu options on the NAS if I navigate via UNC path, i.e. \ymir\multimeda\photos. It pops right up in these situations.

It is only when I go via the symlinked folder that this appears to happen. Does anyone have any advice on whether this is something I can fix myself, or whether this is an issue with Directory Opus?

Windows 7 64-bit
Directory Opus 10.5.2.0 (1913) x64
Qnap TS-459 Pro+, Firmware 3.8.1 Build 20121205

Thanks and regards, Jay

The first thing I would try is the context_menu_debug method described in Crash, exit or high CPU when right-clicking certain files.

That will tell you if it is a shell extension (and which shell extension) that is locking up on that drive.

(It's also worth checking if the same thing happens in Windows Explorer, in case Opus isn't involved at all.)

Thanks for the response. As I said, I don't have a problem right-clicking on local drive folders and files generally, or via UNC, so it seemed unlikely that doing the shell extension debug thing would show anything, however I've just tried your other suggestion and right-clicked a file in Explorer and it does the same thing, so it is looking like not an Opus problem. I never usually use anything other than Opus. Off to look elsewhere for a clue as to what is happening then. I guess it could be a Windows shell extension having problems. Cheers.

Selected the option to hide Windows items on the context menus and right-click now works on these folders and files, unless I hold shift so again confirming that it's not a Directory Opus issue.

Since it's happening in Opus and Explorer, but not when Opus is configured to ignore shell extensions, it probably is a shell extension going wrong.

That it works when right-clicking other types of folders just means the shell extension is only going wrong on certain items, which is pretty normal.

(It may not be the shell extension which is to blame: It might be doing something completely legitimate, but unusual, which the drive responds to incorrectly. Or it may just be doing something wrong.)

As it's a share that's symlinked to a folder on a local hdd, I can access the same file via the symlinked folder path or via the UNC share name. When accessing the share via UNC over the network the shell extensions don't seem to cause a problem. Since it's the same file you'd think it was the same shell extensions in effect, but maybe some disable themselves when going via a share. I've had guests round today but will look at the debug method as soon as I have the time to try an isolate if it's a particular one. Thanks.

Just to update, using the DebugView method and then excluding the CLSID it looks like it was one related to Carbonite.

CLSID: {FE8BD682-9A64-4740-A92B-EE7E5F7FA0A5} (ContextMenu Class) (C:\Program Files\Carbonite\Carbonite Backup\CarboniteNSE.dll)

Telling Opus to ignore this one, and can now pull up the context menu with no problem. Thanks again for your help.

It's worth reporting that to the Carbonite team, in case they want to investigate.