windowssymlinkmklink

How are Windows symbolic links treated by the apps?

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?
Solution

  • 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.