For Windows users the File Manager now supports many complex file system redirections like hard and soft links, mount points, etc. But one thing not supported is "Windows Shell Links". These are the oldest and easiest types of links to make in Windows. We have had requests to support these for more than a decade. For example, you can copy any file system item to the clipboard and then "paste shortcut" to make a file system item that redirects to that item. Once this patch is applied any valid shortcut files will no longer show their ".lnk" extension, just like in Windows Explorer, and use can use them in File Browser as expected.

Mac Alias Changes

Currently Mac alias support is limited to supporting aliases to folders. This patch allows aliases to blend files - for opening or appending - and for aliases to drives, files, images, videos, etc.

Display Changes*

Currently we are showing all folders that are symlinks or aliases with big arrow inside:

However this is a bit limiting. It cannot indicate any other information about the folder besides this one attribute. And this cannot be applied to links to documents. So this patch changes the "link" indicator to a smaller arrow at the bottom-left. This means we can indicate that an item is a link/alias/shortcut while also showing other information. Following are various different types of links made possible:

I wanted to avoid actually returning early as I have to clean up the memory allocated by BLI_file_read_binary_as_mem(). But I have changed that flow to make it easier to read and follow. Hopefully for the better. LOL.

Macs have aliases, which is a very similar file-based redirection. We have a patch around for that somewhere. Although that should just be a a few lines in total, but should work with everything I am doing here.

Should use BLI_path_extension_check.

Thanks! Done.

Still lots of experimenting to do around this. Shortcuts to folders is the most needed and also the easiest to get working. Shortcuts to ordinary files should work so will continue looking at this. But there will remain some possible shortcuts that are impossible to support. Some because they are just inapplicable, like a shortcut to Control Panel, or shortcut to Network Neighborhood. And some oddball types use some things that are not specified in the specification (the variable data inside ItemID). Some people have reverse-engineered this (https://code.google.com/archive/p/lnk-parser/), I'd rather stay with what is published in the spec.

I'm liking this new way of showing links, aliases, hard links, symlinks, etc. It means I can indicate more about the target, if needed, and it looks nicer.

Although this code is currently turning all lnk files into some link, at the end of the day I would be leaving unsupported types without a redirection path and with their ".lnk" extensions intact.

Maybe. I haven't explored that mostly because I don't know to call those things. LOL.

But if you can offer any hints, then we could always put support for this in the win32 ghost files if we need to call them from C++

I'd take that over reverse engineering the .lnk format

For sure. Although the only parts in the spec not actually specified are obscure things we generally can't support. Basically they put those known Folder Ids in there for things like "shortcut to control panel" or "shortcut to network neighborhood". But of those there are some that would come in handy if we can do so.

Maybe. I haven't explored that mostly because I don't know to call those things. LOL.
But if you can offer any hints, then we could always put support for this in the win32 ghost files if we need to call them from C++

No they are usable from C, probably easiest to start with this and kinda play with it to see if it has the info you need

Actually looking at this again my memory is being refreshed a bit. That function can take up to a second to resolve links sometimes and people report that it can crash. The usual response to that is to to parse the lnk file yourself. And all examples of that pretty-much do it the same way as I am here, skipping over that ItemIDList stuff.

Just realized that even if that IShellLinkW takes too long too resolve I could just use a hybrid approach. Quickly parse the lnk file just to determine if is a link and whether to a file or folder and set flags and display as appropriate. But then only resolve the shortcut with IShellLinkW when we actually click the thing.

Updated to current state of master. Also now have a strategy to deal with links that are invalid, point to paths we can't use, or are of a type we cannot support. Still not working with shortcuts to image files though.

Looks OK, there are issues building on Linux (and I assume Apple too).

Whoops, will fix that. For Apple, they have a function with the same name elsewhere that deals with their alias files, which are almost identical (file-based redirection). But yes, will make sure it compiles on Linux.

Note that my own hope for the near term is to support shortcut to folders only. The rest of this experimentation is just me wondering how much could be supported eventually. Not all things are even possible, like shortcuts to Control Panel, or Network Neighborhood, etc. But knowing that at some shortcuts to files might be possible is enough to plan for marking such things visually better.

And also now dealing with multiple-selection without crashing. This situation is a bit interesting in that we have a single root dir and multiple file names, which doesn't work well if any in the group have full absolute paths. Now just doesn't add a shortcut/alias to the selection list in case of selecting multiples. So you can select a single alias/shortcut or multiple regular files, but not a combination. Works out okay in practice as we don't normally have piles of shortcuts to files anyway.

Fixing an issue pointed out by @Ray molenkamp (LazyDodo). There was an unneeded call to count_utf_16_from_8() that was used (incorrectly) as an argument to conv_utf_8_to_16(). This had the potential of not handling an error if the passed filepath converted to a UTC16 that overflowed my buffer.

Didn't dig too deep, but everything seems reasonable. I noted some points, they are just cosmetic though.@Bastien Montagne (mont29) should get a chance to intervene here, he's module owner -- Feel free to remove yourself as reviewer if you think it's gotten enough treatment already :)

The icons look quite small compared to the screenshots above. Not sure if that is the intended size or if that's a hiDPI issue. Default DPI on Retina:

For these hidden items the icon is also barely visible, although I don't think that's a big deal.
I did prefer the previous arrow icon though. The more round one feels much closer to the standard icon used in Windows, macOS and Linux for me.