Are symlinks on Windows really such a big issue? I’ve never heard of projects using symlinks in their tree. If Windows developers are complaining about you doing something unusual, why is it their fault?
Apparently being the best in symlinks hasn't made a difference in the Year of Desktop Linux.
The problem people are running into is that the OS hasn't been designed with wild symlinks in mind and therefore can't guarantee its security principles if any user is able to symlink however they please; if I read the context [1] correctly, it seems like an elevation of privilege is suspected to be very easy to gain if a standard-level user is allowed to place arbitrary soft links on a file system.
I see little reason for Microsoft to enable the "all users can soft link" setting by default. They'd need to audit their OS and userland code to determine where soft links may introduce vulnerabilities in order to change the default and a few developers that absolutely insist on using soft links inside git repos for some obscure reason isn't going to get them to make such an effort.
Microsoft has made enabling the feature a bit easy [2] but I can find very little about the security analysis done for this change, so enabling dev mode might open your computer up to a whole class of vulnerabilities.
I personally don't see a reason to use symlinks in a dev environment, but I suppose *nix developers think otherwise, probably to duplicate files across a source repository for some reason? If your intent is to work together cross platform then there are loads of restrictions you need to deal with. Linux applications tend to trip up over CRLF, every file system has their own stupid restrictions, build tools and shell scripts need to somehow become platform agnostic, you name it.
You can blame Windows for being different but the truth is that Windows is still the most commonly used desktop operating system in the world by a huge margin. macOS and Linux are the odd ones out and there is no good reason why the POSIX/X11 system design is better or worse than Cacoa or Win32; it's a mere difference of convention.
[1]: https://docs.microsoft.com/en-us/windows/security/threat-pro...
[2]: https://blogs.windows.com/windowsdeveloper/2016/12/02/symlin...
It's not that unusual, though, a quick search turns up 1.1k GitHub repositories with `git config core.symlinks true` in their documentation or CI pipelines - including quite popular projects like Ava, Apache Arrow, Solana, Chrome Devtools, adobe-fonts, IBM/houdinID, travis-ci, RabbitMQ, various Google projects & more.
NTFS does support them, however. Is Git just not supporting them properly?
Asking because I doubt e.g. my mom knows that NTFS has symlinks.
https://docs.microsoft.com/en-us/windows-server/administrati...
One is even a professional AAA DirectX gamedev.
I think you misread that line.
I think they misread the line.
(Whether it was right or not, so you don't need to tell me anything about that.)
From my point of view, even when someone is on the correct 'side' of an argument, if they got there by mistake it's still important to point that out. Both fortran77 and CoastalCoder can be wrong at the same time.
Is "I think you misread that line" far ruder than I thought it was?
...surely "I doubt my mom knows" wasn't supposed to be a developer anecdote that I misunderstood massively?
1. You run into it, go "AH, wow, okay, I'll enable Developer Mode"
2. It still doesn't work, you're confused, you Google around a bit more and find out actually you also need to use a Git config option
3. You retry, now the symlinks work, but your compiler fails because "Destination Path Too Long", huh, that's weird
4. You google a bit more, and discover you need to set a registry option. So you do it, but you still get that error..
5. You discover there's another Git option you need to set
And then you're like, hey, what was I doing again? Where did the last hour of my time go? It's death by a thousand paper cuts.
https://docs.microsoft.com/en-us/windows-server/administrati...
My understanding is Microsoft's concern is that applications and OS components not expecting them could lead to security issues. Not sure how real that concern is, but that's the excuse I've heard.
Bufferoverun I guess? I haven't programmed Windows in years, but there's plenty of code I've seen that is pretty much
char path[MAX_PATH];
res = some_func(&path);
Windows is horribly hard to learn. In a day, i learned how to create file, directories, change the stats on those, execute diff and patch, an do weird string modifications with grep and cut (and learn to commit and push with git). First day on an UNIX machine. First work week on a windows machine (at that time, i had already built a LFS): we have those two project with two different version of (proprietary JS front framework) and (weird php framework). Those don't use the same version of mycrypt.dll (and others, but this one i will remember for at least two dozen year). With the support of non-intern engineers including a windows DBA, it took us a week to manage to install the two different versions.
A week prior, i was linking to a previous version of Ruby for my RoR app (it was around 2013).
But since, i really respect windows sysadmin, they are the best of us. I will just never, ever want to work on a windows server again. I like learning, but putting that much effort for this little rewards? not worth.
https://docs.microsoft.com/en-us/windows/security/threat-pro...
Developer Mode is just a bundle of useful developer-related settings and components that get applied to the device when enabled.
There's a post here about this from the Developer Mode angle with a bit more background:
https://blogs.windows.com/windowsdeveloper/2016/12/02/symlin...
Or do you just want it to be phrased "not supported for users on normally configured systems"? There, then.
Yep.
We backed off to "not supported on normal systems", which is a reasonable change to me.
You mentioning junctions is not even close to a solution, and I am not moving the goalposts. If junctions worked, the complaint wouldn't have been needed from the start. No, this is about actual symlinks, not a similar feature that can do 5% of what symlinks can do.
Windows, oh bummer you need special permissions to be able to call it.
The feature is there and supported.
However using symlinks just isn't a thing in the Windows culture, people use at most Shell shortcuts.