I've had a long-standing issue that I've finally decided to stop ignoring. When I double-click a symbolic link it opens the target instead of the link itself (The link is opened if I right-click and choose open). For example, I create a new text file named example.txt, and a symbolic link that points to it named example_link.csv. example_link.csv should open in LibreOffice when double-clicked, but instead it opens in Notepad++, and the title bar clear shows it is example.txt that Notepad++ opened, not example_link.csv.
This old post (Relative Symbolic Links to Executables) is from someone that had a different symbolic links issue, and the brainstorm in the reply is that the links could be dereferenced prior to execution. If that was implemented, that would appear to be the cause of my issue.
I would just like to be able to disable the behaviour at least, if not limit it to certain file patterns. Not a huge priority either; I can't remember not having this issue, and right-click->Open is not overly burdensome.
I think that has been implemented. It's may even be the exact reason for the behaviour you're seeing. What you want is for links to not be dereferenced before they are launched.
If the link with a different extension is there to give a quick way to open the same file in a different tool (e.g. open .csv as text in a text editor), we have lots of ways to do that, if that would help.
I think that has been implemented. It's may even be the exact reason for the behaviour you're seeing. What you want is for links to not be dereferenced before they are launched.
If the link with a different extension is there to give a quick way to open the same file in a different tool (e.g. open .csv as text in a text editor), we have lots of ways to do that, if that would help.[/quote]
Alas, this was just an example; in my most common case, both the target and the link have the same extension, but the program doesn't understand the path passed to it on the command line, which is in the form \?\Volume{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}\example.txt, despite the link targeting C:\foo\bar\example.txt, where bar is a junction to a folder on another drive. And XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX is the correct volume id for C:\foo\bar.
I'd like to try to reproduce this. The \?\Volume... syntax should only be used as a last resort when no path with a drive letter can be found for the same volume or mount point.
CreateSymbolicLink(), but I can reproduce it with mklink.
Let's see...
C:\eggs\favorites\lumberjack.txt is a symbolic link to C:\eggs\spam\lumberjack.txt.
C:\eggs\spam is a junction to C:\volumes\raid\spam.
C:\volumes\raid is a mount point, with no drive letter. As you described, since it has no drive letter, the last resort behaviour is exhibited. Not sure why, since all the links are defined with absolute targets...
But in contrast, if I make a link to a target that resides on a drive with a drive letter, the path passed on the command line does use the drive letter.
Anyway, seems to me Opus is being too clever by half in trying to find a path to a file that uses no links, not even mount points.
It's done due to a compatibility issue with some cloud storage shell extensions.
I'm not sure why it isn't picking up the drive letter there, with a symbolic link to a junction to a mount point to a volume with no drive letter, but we'll put it on the list to take a look at it.
Ugh. Workarounds. Worse, workarounds to (I assume) mitigate other programs flaws.
Hopefully something simple can be done, like an option to disable it. I don't like the idea of it second-guessing me; if I wanted it to open the original path I'd use a shortcut. When I use a link I mean to use the link.
Unless we notice any problems at the last minute, the next update should resolve both issues in this thread:
[ul][li]Double-clicking a symlink.txt to original.csv will open the file in a .txt editor, and similar.[/li]
[li]Double-clicking a symlink that ultimately resolves on a volume with no drive letter will work.[/li][/ul]
Finally had the chance to test it on my laptop (I wish DOpus didn't seem to always require a restart when upgrading...); looks like it now only opens the target if it's an exe? Good enough for me.