Yes, in theory, Windows has rocketed into the 21st century with symbolic links. However, you can’t make them in Windows 7 unless you’re an Administrator, or unless you manage to give yourself “SeCreateSymbolicLinkPrivilege.”
Giving yourself this privilege is possible with Professional/Ultimate versions of Windows, but not Home Premium, via secpol.msc, which just doesn’t exist (and can’t be downloaded). (Funny, I don’t recall the comparison chart having a checkbox for “can actually use computer” that was missing from Home Premium.)
If you try to set this for yourself, don’t bother trying to use C# or PowerShell. You’ll need to manually wrap the unmanaged C++ advapi32 APIs, and pass all kinds of structs and pointers back and forth.
In the end, just give up on whatever it was you wanted to use symlinks for.
Huh? I used mklink all the time, and it’s great – easiest way to get My Docs off your C: drive (in my case a small SSD) and move it elsewhere. Also works for other magic directories like PROGRAMDATA.
1. Technically, it’s “cmd /c mklink”, because mklink is a cmd.exe builtin and not its own program. (This will save PowerShell users the confusion.)
2. Yes, you can use it as you described, but only if: A. you’re Administrator (effectively), or B. your local security policy gives normal users the SeCreateSymbolicLinkPrivilege.
3. If you don’t have the “professional” or “server” versions of Win 7, you won’t have the required program(s) such as secpol.msc that let you manipulate your own security policy.
4. Hence, if you want a more repeatable and reliable solution than “start PowerShell as Administrator manually with some right-clicking,” you’re up Shit’s Creek. (Example: you might want to run a script to set up everyone’s development sandbox with appropriate local env vars and config files, all of which are version controlled, but only one of which should be the local active copy on any individual box. You can rely only upon the standard facilities of PowerShell. Symlinks are right out because you can’t guarantee that SeCreateSymbolicLinkPrivilege is enabled, or even *can be* enabled, on each dev’s box.)
Yes, I know, one could always “runas /user:Administrator”, but then by doing that we’ve effectively destroyed the “least privilege” principle, because the answer to any hurdle becomes to adopt the *most* privilege.
You can give your normal user account the permission with polsedit:
http://polsedit.southsoftware.com/
You are forgetting that most people run standard in admin mode. So its not a problem for those.
Most people I know run with a hacked code, so they all have ultimate of course.
It’s not an issue.
Kika is wrong here. It is an issue. Just because it’s not an issue for a subset of users (power users), the “workaround” violates good security principles (not running common commands as administrator) and doesn’t account for some environments where the workaround is simply not viable.
Rlucas is right that if the privilege to create symbolic links is not present by default, it should at least be possible to enable it in as straightforward fashion with no more than one (built-in) command (or powershell script), but as he points out, it is not.
Finally, I wanted to add that this is not the only surprise regarding symbolic links. Did you know that if you try to delete a directory tree using Powershell and that tree contains a symbolic link to another directory, Powershell will _traverse_ that symbolic link and recursively delete its content too?
Let’s hope our friend Dan Shapiro doesn’t try to remove one of his symbolic links using Powershell and accidentally delete all of his Documents.
If you think that’s ugly, please vote for the issue in MS Connect: https://connect.microsoft.com/PowerShell/feedback/details/727149/powershell-rm-rec-traverses-symbolic-links-and-removes-items-in-target