The Windows’ NTFS file system has supported symlinks since Windows Vista. However, it hasn’t been easy for Windows developers to create symlinks. In our efforts to continually improve the Windows Developer experience we’re fixing this!
Starting with Windows 10 Insiders build 14972, symlinks can be created without needing to elevate the console as administrator. This will allow developers, tools and projects, that previously struggled to work effectively on Windows due to symlink issues, to behave just as efficiently and reliably as they do on Linux or OSX.
Pretty sure a few developers out there are rolling their eyes, sighing ‘finally’.
There might not have been a command line tool built in, but the file system certainly supported links since win2k. See the tool below, which I actually used on Win2k.
https://technet.microsoft.com/en-us/sysinternals/bb896768.aspx
I thought so, because I remember creating symlinks using cygwin’s xterm and ln -s. Hmm, might have created .lnk files, can’t remember. But I think to remember that I could do something fileystem related in xterm that I thought wasn’t possible in Windows, without it resulting in a hack like .lnk.
Win2k supported directory junctions. Vista supported symbolic links. Often the two could be used interchangeably, but they are different: directory junctions are only for directories (not files); and they are evaluated on the server, so no client side redirection could be performed, including to a different server for example.
Directory junctions still exist, and can be used without elevation (sigh.) Use “mklink /j”.
Actually some forms of symlinks has existed since windows 95. They just required special files that redirected to the real file (.lnk). Of course that only worked in application that chose to dereference the symbolic links, so it was never as elegant as in POSIX.
If I recall correctly, hardlinks were supported for many moons, symlinks (which are a bit different) were not supported pre-Vista. Granted, I could be completely wrong about that, but I do know Windows 10 was the first to finally support workspaces. Seems they are trying to be more *nix-like, so is that copying Linux because it is popular enough, or Mac because they are losing more desktop share?
You’re referring to multiple desktops?
Windows has actually had support for this since NT4, there just wasn’t an UI to enable it. There was an XP PowerTool that enabled it for XP, tools in the SysInternals tools that enabled it for Vista and later, and various other solutions for other versions (Some Microsoft made, others not), all utilizing the underlying API support.
SysInternals People made bearable what had been unbearable. [%]D
The biggest surprise here is it still requires developer mode, so unprivileged users can’t create symbolic links by default. Previously, unprivileged users could create symbolic links if given the privilege (secpol.msc, Local Policies, User Rights Assignment, Create symbolic links.) See https://technet.microsoft.com/en-us/library/dn221947(v=ws.11).aspx .
Unfortunately there was no way to make an unelevated administrator able to create symbolic links, so I hope this change fixes that.
Now if they could just replace shortcuts with symlinks they might be able to catch up to the state of BeOS in the 90s.
I would much rather be using BeOS now. If only it survived!
It did. It^aEURTMs called Haiku OS. https://www.haiku-os.org/
No it didn’t! I have a install of Haiku and it still lacks some of the BeOS features. It may be getting close but it still doesn’t replace it yet, as close as ReactOS replacing Windows I think.
Symbolic links can be used instead of shortcuts. Shortcuts provide additional functionality, such as application icon and starting directory, which is why they’re typically preferred by Windows and installers. Note that KDE/GNOME ended up with a very similar solution for similar reasons in the form of .desktop files.
Except that .desktop files are superior to .lnk files for that purpose in that they’re intended to encode everything a desktop environment needs to know to integrate an application smoothly, including mimetypes supported for file associations, a cue as to how the command accepts arguments (single or multiple, path or URL), and other supplementary stuff, such as definitions for new entries to be added to the file manager’s context menus.
In a way, they’re sort of PIF 2.0.
(Now maybe we can get an extension to the .desktop spec which codifies the retrofitting of legacy applications with opportunistic sandboxing rules and we’ll really have PIF 2.0.)
I wonder, what made them suddenly think “modern” devs use or need symlinks. I think these people are just out of whack.
I suspect it’s all tied into the reasoning for a clunky Linux environment running inside Windows – “modern” developers aren’t using Visual Studio workflows, they’re using *nix dev workflows.
Us unix based developers aren’t going to pay money for the privilege of having updates and advertising forced on us.
The real play sadly is to the PHBs, MS’s target audience. They hold the dollars and are the ones who can force us to develop on this platform.
bnolsen,
I had to look this up, and I’m left to conclude you mean “Pointy Haired Bosses”?
Ah yes, the definitely clunky “Windows Subsystem for Linux” (shouldn’t that be the other way around? ) intro’ed with the Windows 10 Anniversary Update.
As I could have guessed, it was a half-baked Microsoft effort with much of the /proc functionality missing, particularly the networking stuff. Also, I was mystified why Linux users weren’t mapped to their Windows users equivalent and you had to create Linux users from scratch.
Welcome to the 1970’s microsoft, glad you could join us!
Too bad they still have the 70s level insecurity.
To be fair, Windows is as secure as Linux (often even more secure) starting with Vista/7. Drop that Windows XP-era mantra “Windows is less secure than Linux”. It is no longer true.
For the typical windows user it isn’t. Installing software from unknown sources is way too easy and ingrained in the Windows culture. With it comes all the malware and the dreadful antivirus industry.
Doing that on linux is an exception rather than a rule.
Edited 2016-12-05 16:10 UTC
Count me in, among those devs.
Sill have that cmd script to investigate why it fails to create symbolic links with mklink /D…
from a non developer standpoint, i dont see the big deal about symlinks. I know that you could have all your stuff the same place and have the OS thing that its were it needs to be as well.
But how in a normal work day does this help make the application better for end users?
It might be something that i’m missing or that this is more for the devops people i keep hearing about but never meet in my day job
Well, I use symlinks to move most of my application-specific configuration files into a Git repository so I can have a specialized, versioned, “roaming profile” with moderated updates. That’s saved me from subtle, unwanted config changes more than once.
Edited 2016-12-05 11:37 UTC
The biggest use is that symlinks let you work around hard-coded paths in applications (For example, Dropbox pretty much forces you to use C:\Users\<yourname>\Dropbox as your Dropbox directory. By using a symlink, you can force it to put that data anywhere.).
One of the other big uses is to have multiple versions of the same application installed and use symlinks to select which one is the default. Most Linux distributions do this with Python and other programming languages (So you might have all of python27, python2, python35, python3, and python visible in $PATH, with python2 being a symlink to python27, python3 being a symlink to python35, and python pointing to either python2 or python3 depending on which is the OS default when you just invoke python. All of that then means that an application just has to care whether it wants Python 2.x or Python 3.x, not which minor version is installed.).
If you have any situation where you’d want files or directories to be available somewhere else other than where they actually are then you’ll find it useful. If not, you probably won’t.
This example isn’t something that you’ll find often (if at all), but just as reference for a non-dev use: back when I dual booted and played games on the computer I had an install of UT2k3 that I could play both on Windows and Linux.
Installing the whole game twice didn’t only mean that it used twice as much space but also that everything I configured in the game I had to replicate on both installations.
So what I did is installing the game on Windows, then on Linux, and then I removed the whole data folder in the Linux install and created a symlink to the game data on the Windows partition (which was easy because the native binaries and the game data were on different folders).
Also for that same game I symlinked some system audio libraries to support some hardware features of an Audigy2, replacing the game libraries. Maybe I could have copied them, but symlinking meant that updates for that library would automatically apply to the library used there.
The same idea can work for any application with hardcoded paths, be it to share between partitions or different computers using network drives or synced folders (dropbox or whatever).
For big data production shops symlinks are pretty critical. You may have multi terrabyte data sets. Under unix you can make multiple views into that data set using symlinks. Under windows its always been “make a copy and modify the file structure”. Hugely wasteful.
Training these windows locked production guys to start using the symlinks is going to be a monumental effort itself.
SUBST, JOIN, ASSIGN
*ducks*
*swings anyway*