[no bug] FileCreateShortcut not working for folder

[Vasco]

Hi sifus,

I create shortcuts to (existing) folders. This worked like a charm for many years but not people switching over to WIN 10 and reporting issues. It appears the AHK FILECREATESHORTCUT does have an issue with the folder name and create the shortcut wrongly therefore WIN 10 cannot open it.

I did check on the folder names and existence of those and this all in good order. The manually created shortcut has the identical Target link as the one create by AHK.
However it seems AHK has issues with the folder name. The target folder has a shape of

\\server\folder\AB 12345-Realization (A12-3.BC)

It appears the .BC) is interpreted by AHK as file instead of a folder causing this confusion.
Since this structure is used by other software we actually have to keep it this way.

Anyone has a workaround for this? I searched the net but the only issue I can find is when the folder is not created yet. But in my case it's ensured the folder is existing since I create it earlier in the script.
During troubleshooting I challenged that to avoid racing conditions or similar but everything is in good order.

Any help is appreciated since my users getting a little upset that this does not function anymore after WIN 10 upgrades
My source code runs over 500 lines which I doubt anyone will read entirely, the line of interest looks like below (straight forward and working fine in the past until WIN10 came in).
If it's related to some settings or similar please point me to the direction and I'll post the related part of my code.

Code: Select all

FileCreateShortcut, %target_folder%, %basedir%\%folder_name_long%.lnk

In attached screenshot you see two shortcuts created. The left one is a manual one by drag and drop and the right one is the one created for the same target by AHK. Left one is working well, the right one does nothing upon click.

Left: created shortcut by Drag & Drop; Right: created shortcut by AHK (not working)

AHK_shortcut.jpg (76.56 KiB) Viewed 1193 times

[lexikos]

AutoHotkey does not interpret the path in any way; it just passes the path to IShellLink::SetPath.

To try to reproduce your problem, I created a folder with the name \\pc\share\WO 113092-Realization (C34-1.EB) and created a shortcut to it with FileCreateShortcut. The shortcut showed type "File Folder", as expected.

I guessed that it could be related to other problems with shortcuts to non-existent files in Windows 10, so I then created a shortcut to a non-existent file/folder. The shortcut showed "AB) File", which was to be expected. There was neither a file nor a folder, so of course Windows will assume that it is a file. I then created the folder, and the shortcut still showed "AB) File" and would not work. If I create a file with that name, the shortcut works.

If I do the inverse manually (create a folder "test.txt", create a shortcut to the folder, then replace the folder with a file), the shortcut still thinks it is a shortcut to a folder, and will not open the file. Evidently there is some difference between a shortcut to a file and a shortcut to a folder, at least on Windows 10.0.18362 (v1903). This was quite clearly not caused by an AutoHotkey bug, since AutoHotkey had nothing to do with creating this shortcut.

As far as I can tell, I see no issue with creating shortcuts to existing folders. If the folders exist in your case, perhaps they are not accessible to the AutoHotkey process.

It seems that whatever creates the shortcut must be able to determine whether the target is a file or a folder. If ShellLink (via FileCreateShortcut) is failing to determine the type, it seems likely that any alternative code would fail in the same way, unless the caller can specify that it is a folder (which cannot be determined by the path alone).

[Vasco]

Thanks lexikos for taking your time to challenge/replicate it.
I'm currently not in the environment to test it but will do so during the week.
You have some points but I challenged the existence before.

"Access right" as issue I like to exclude since the folder was created by the same script in the same instance.
This brings me back to racing condition may be the only cause of this struggle. I will try with a ridiculous sleep in between. Let's see if that does any good
I'll revert (either way) once I got a chance to access the script again.

[Vasco]

Hi Lexikos (and everyone monitoring)

The issue is found. It's indeed (somewhat) related to folder not accessible.
In the target folder an additional \ sneaked in while resolving mapped network drives to their \\server\ counterpart.
Unfortunately it broke the link for the shortcut but was already resolved in the target displayed in the shortcut properties.

The user specific link was:
z:\AB 12345-Realization (A12-3.BC)
with Z:\ mapped to
\\server\folder

The supposed link was:
\\server\folder\AB 12345-Realization (A12-3.BC)

The actual link referenced was:
\\server\folder\\AB 12345-Realization (A12-3.BC)

The link stored in the properties was
\\server\folder\AB 12345-Realization (A12-3.BC)

extensive troubleshooting and debug printing showed this. Once the additional \ in the link was removed the Folder shortcuts worked fine and the mapped network drive was properly resolved.