2

I thought that symbolic links in Windows 10 behave similarly to Linux symlinks, i.e., they are transparent to the apps. However, I'm confused by the actual behavior.

As an example, I've both softlinked and hardlinked the same CSS file:

$ mklink softlinked.css Default.css
symbolic link created for softlinked.css <<===>> Default.css

$ mklink /H hardlinked.css Default.css
Hardlink created for hardlinked.css <<===>> Default.css

soft and hard link

The hardlink behaves predictably (is indistinguishable from the original file) but I don't understand the soft linked one. See for example this:

enter image description here

Also, when the CSS is consumed by the Caret editor, the hardlinked stylesheet works fine:

enter image description here

while the softlinked is broken:

enter image description here

The questions are:

  1. How do the symbolic links actually behave on Windows?
  2. Can soft links be made transparent to the apps? By transparent, I mean the app would always see the file as being on the symlinked path (...\symlinked.css) and never resolve to the original path (...\Default.css). Is there some Windows registry settings or something?
Borek Bernard
  • 50,745
  • 59
  • 165
  • 240
  • 1
    It should probably be noted that hard links won't work reliably either, since it is common for a save to be implemented as a delete-and-recreate (which breaks the hardlink) rather than a simple write. – Harry Johnston Mar 29 '17 at 21:25
  • @HarryJohnston yeah that's what I was thinking as well. Links are surprisingly troublesome on Windows. – Borek Bernard Mar 30 '17 at 07:30

3 Answers3

5

Symlinks are transparent to applications that are using the underlying file system, e.g., CreateFile() and friends, unless the application makes a specific effort to be aware of them.

However, they are not transparent to applications that are using the shell namespace (for example the standard Open File dialog) because the shell treats symlinks as if they were shortcuts, even to the point of modifying the displayed icon. Whether this was a sensible decision on Microsoft's part is a moot point at this stage, since it isn't about to change. So far as I'm aware, it is not configurable.

In practice this usually means that symlinks will behave transparently for non-GUI applications and for internal files (DLLs, built-in templates, configuration files, etc.) in GUI applications, but not for the user's documents.

So your first two examples (the way Explorer displays the files and the behaviour of Notepad++) are features rather than bugs; like it or not, this is the way Windows is designed to work.

Your last example does appear to be a bug (or at best an undesirable design limitation) in the application in question. It might be worth contacting the vendor.

You should also be aware that creating a symlink requires administrative privilege, and by default they don't work at all over network shares. Personally, given all these limitations, I've never found them very useful. For most user tasks I would use shortcuts instead, and for most system administration tasks junction points are more reliable.

Harry Johnston
  • 35,639
  • 6
  • 68
  • 158
  • Great answer, thanks. It should be noted that administrative privileges will no longer be needed when Creators Update comes in two weeks' time :) – Borek Bernard Mar 30 '17 at 07:31
  • @Borek, interesting! Although it looks like that will only be true [if the machine is in Developer mode](https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/#YKZcKPd1JpFhCJ9b.97) to begin with. Hopefully after a year or two, if this doesn't cause too many security issues, they'll open it up further. – Harry Johnston Mar 30 '17 at 20:17
  • I've used symbolic file links across the network before and they worked fine. For example, I had a configuration text file for an application that I wanted to share across multiple computers. I put the file on a file share and then created a link to the file on each computer that needed to use it. – Jack Mar 30 '18 at 13:56
  • 1
    @Jack, yes, that's local to remote, which is enabled by default. So is local to local. But remote to local (a symlink on a network share pointing to a local path) and remote to remote (a symlink on a network share pointing to a network path) are both disabled in the default configuration. – Harry Johnston Mar 30 '18 at 22:46
2

They should be transparent to most apps but some apps are to clever for their own good.

They might pass FILE_FLAG_OPEN_REPARSE_POINT to CreateFile, or be too aggressive when "verifying" file attributes and choke on FILE_ATTRIBUTE_REPARSE_POINT.

In your specific case, I'm guessing the advanced editor should use FOS_NODEREFERENCELINKS in their open dialog. The CSS switcher might be using FILE_FLAG_OPEN_REPARSE_POINT and you should be able to verify that with Process monitor.

There is no magical registry entry you can use, you have to contact the application authors.

Anders
  • 97,548
  • 12
  • 110
  • 164
  • Are there similar "issues" on Linux or is this Windows-specific? In practice, it makes it hard to trust soft links because applications may break, depending on how they are coded. – Borek Bernard Mar 29 '17 at 11:12
  • Hardlinks and junctions have been around since 2000, symlinks were new in Vista and most people are not used to them on Windows so there are bound to be more issues. – Anders Mar 29 '17 at 13:20
  • I think Notepad++ is working the way Windows users would expect it to, by reporting the file's "real" name instead of the link's name. At any rate, expect resistance to changing it, because [every change breaks someone's workflow](https://xkcd.com/1172/). :-) – Harry Johnston Mar 29 '17 at 21:21
  • @HarryJohnston No? I expect Windows to dereference .lnk files and open the target file by the targets path but for symlinks I expect it to open the targets file stream but with the symlink path. In hex editors etc. I expect it to open the raw .lnk file as well. – Anders Mar 29 '17 at 22:03
  • But symbolic links are *basically* just a fancy new kind of shortcut (or at least that's how I would expect a typical end user to see them) so it seems reasonable to expect them to behave the same way as shortcuts. At any rate, Microsoft seem to think that this is the correct behaviour, since there doesn't seem to be any way to tell the Open File dialog to resolve shortcuts but not symbolic links. (?) – Harry Johnston Mar 29 '17 at 22:11
  • To put it another way, why should the application lie to the user about what file it is actually opening? – Harry Johnston Mar 29 '17 at 22:13
  • 1
    @HarryJohnston You could tell the dialog not to dereference anything and then decide based to the chosen file. And for a directory symlink, do you expect it to change the entire upstream path or just act transparently as a normal folder in most instances? I just expect the application to call CreateFile on the file I chose, whatever tricks are happening at the FS level should not matter to the app. – Anders Mar 29 '17 at 22:18
  • Hmmm. I would expect non-GUI applications to behave as you describe, and even GUI applications when dealing with internal files. But if you're using the Open File dialog, you're looking at the shell namespace rather than the underlying file system, and the conventions are different. Yes, you *could* make your GUI application treat shortcuts and symbolic links differently, but the fact that you would have to implement this yourself makes me think that Microsoft, at least, don't consider that to be the behaviour the users would expect. (That doesn't necessarily mean they're right, though.) – Harry Johnston Mar 29 '17 at 22:34
  • I basically agree with what you are saying but 99% of apps are not setting `FOS_ALLNONSTORAGEITEMS` and they are not going to read/write their content with a `IStream` they get from the PIDL/`IShellItem`. The shell namespace is what the common dialog uses but most apps are stuck in the pre-Vista era of filesystem paths and `CreateFile`. On XP and older you will always get a FS path even if the UI uses the shell namespace. – Anders Mar 29 '17 at 23:15
1

A file is a pointer to a certain node.

When you create a hard link you are just making a new file that points to the same node as the original file.

When you create a soft link you are not making a pointer to a node, but to a file. Because of that soft link resolves it's path to the file it points to.

Since symlink contains both it's own path and path it points to it really depends on application developers to choose which path they want to put in their UI.

Djuka
  • 505
  • 5
  • 19