Support FileFolder / Folder Shortcuts / Network Locations shortcuts

What feature or improvement do you think would benefit Files?

When creating a shortcut to a network location, Windows Explorer will create a "FileFolder". This is a read-only directory that contains a desktop.ini file with this content:

[.ShellClassInfo]
CLSID2={0AFACED1-E828-11D1-9187-B532F1E9575D}
Flags=2

And it also contains a regular shortcut named target.lnk that points to the destination.

When the folder containing these two files is marked "Read-only", Explorer will treat it as a "fake symlink". The breadcrumbs will track the path navigated into this folder, but the actual locations of all items within are not modified (which IMO is the defining difference in behaviour between these weird objects and regular ol' junctions/symlinks)

As it is right now, Files does not support these folders. Instead, it will happily navigate into the folder's "real" content, ignoring the shortcut. While I appreciate this is a somewhat... esoteric shell feature in Windows, it is quite useful:

Because it's a shell feature and not a filesystem feature, it works as a safe way to create "symlinks that don't have the same risk as symlinks". Delete/move/copy operations treat these folders as-is, with no special behaviour.
Many other programs that use system-provided open/save dialogs interact better with FileFolder shortcuts than bare .lnk shortcuts. In some scenarios, double-clicking a shortcut will give you an "invalid file" error rather than navigation. You must right-click and manually navigate instead of "Select"ing the shortcut.
There is no "duplication" of file/folder locations when using these shortcuts. You can address filesystem items with multiple paths when using symlinks or junctions to achieve "transparent" shortcuts, whereas this feature does not allow that. Explorer will happily resolve a path and open a directory there, but if you go to view the address, you see the "real" location of the folder on disk. Files cannot be identified using paths within a FileFolder's path.

Requirements

When a folder is marked "read-only", check for the existence of a desktop.ini file directly within it. Note: There is no constraint on the attributes of desktop.ini
If desktop.ini exists, read it. If it has the CLSID 0AFACED1-E828-11D1-9187-B532F1E9575D registered under .ShellClassInfo, check for a shortcut named target.lnk.
If this shortcut exists, and its target is both a folder and accessible, treat the containing folder as if it were the target. Any desktop.ini file within the target folder should then be applied to this folder.
When Files is asked to navigate to this special folder, it should also check for, parse, and handle the target as redirected.
The folder must only be treated/parsed this way when it is being displayed in an interface or as part of navigation. When any other operations discover this folder (Eg. copy, move, delete), it must be treated as a plain folder without any special behaviour.

Files Version

2.4.49.0

Windows Version

Windows 11 22H2 22621.1265

Comments

Clear steps for manually creating a FileFolder:

Create an empty folder.
Create a shortcut to your folder destination within the folder.
Create a new file named desktop.ini and paste in the content from above.
Go up one level and mark the new folder as "read-only".

files-community / Files