7 ms·

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 doin

• slimsag 4y ago
  Certainly better to avoid it if at all possible, and I'll be eliminating them specifically to improve Windows compatibility. 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.
  • colejohnson66 4y ago
    I agree that Windows could do more to support the developers on other platforms. Symlinks just seem like a petty thing to complain about IMHO. Didn’t realize how common they were though. NTFS does support them, however. Is Git just not supporting them properly?
    • fortran77 4y ago
      That's exactly it. Windows developers know NTFS has Symbolic Links https://docs.microsoft.com/en-us/windows/win32/fileio/creating-symbolic-links?redirectedfrom=MSDN https://docs.microsoft.com/en-us/windows/win32/fileio/creati...
      • bilekas 4y ago
        Maybe I missed something on this discussion but symlinks and NTFS are not really related.. They have them yes, how they're handled is different.
        • fragmede 4y ago
          How are they not related? If NTFS didn't have symlinks we wouldn't be having this discussion. Critically, the modern standard for removable drives, exFAT does not support symlinks, so you can't count on Windows' support for symlinks if the user is git cloning on a drive that's using exFAT.
          • pjmlp 4y ago
            https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/mklink https://docs.microsoft.com/en-us/windows-server/administrati...
            • forgotpwd16 4y ago
              Pointing to this page is meaningless. `mklink /d` only works on NTFS but errors out ("The device does not support symbolic links.") on exFAT. GP acknowledges NTFS has symlinks and remarks that exFAT doesn't.
              • pjmlp 4y ago
                NTFS is the only filesystem that matters for Windows developers.
      • CoastalCoder 4y ago
        What's the standard for being an "actual Windows user"? Asking because I doubt e.g. my mom knows that NTFS has symlinks.
        • pjmlp 4y ago
          Is she a Windows developer? https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/mklink https://docs.microsoft.com/en-us/windows-server/administrati...
          • slimsag 4y ago
            The developers who complained to me about this are Windows developers regularly. One is even a professional AAA DirectX gamedev.
            • pjmlp 4y ago
              Apparently not professional enough to know a feature as old as Windows 2000.
        • Dylan16807 4y ago
          > What's the standard for being an "actual Windows user"? I think you misread that line.
          • slimsag 4y ago
            Their message originally read "Actual Windows developers know NTFS has Symbolic Links"
            • Dylan16807 4y ago
              So it did say "developers" and not "users"? I think they misread the line. (Whether it was right or not, so you don't need to tell me anything about that.)
    • slimsag 4y ago
      Well, it feels 'petty' and simple until: 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.
      • deleted 4y ago
        [deleted]
      • giantrobot 4y ago
        Yak shaving.
    • pjmlp 4y ago
      It does support them, mklink. https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/mklink https://docs.microsoft.com/en-us/windows-server/administrati...
      • colejohnson66 4y ago
        Yes, Windows does, but this post is complaining about support. Which led me to ask if Git is the problem. Cause Git also supports symlinks, but is clearly having issues on Windows.
        • bogwog 4y ago
          I would assume the issue is that they need to disable symlink support by default on Windows because symlink support is disabled by default on Windows.
    • Pathogen-David 4y ago
      NTFS has supported them for ages. The main issue is that they're locked behind elevated permissions or having developer mode enabled (as of Windows 10.) 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.
      • nemothekid 4y ago
        >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); from there you put in a large path and then you get your RCE.
        • MereInterest 4y ago
          That would be for removing the 260 character limit, not for enabling of symlinks.
      • MereInterest 4y ago
        I've looked before, and have never found a definitive answer from Microsoft. I've heard some speculation that it the nebulous security issues would be from a program that checks the permissions of a symlink's target, then opens the symlink. An attacker could then modify the symlink after the permission check but before the file is opened, escalating access by pointing to a restricted file.
        • pxc 4y ago
          It's a kind of attack called a symlink race, which is also possible on other operating systems. There are kernel parameters for hardening against symlink races on Linux, and they just disable symlinking into world-writable locations. I'm not sure why Windows can't use a less invasive mitigation like that, but I guess there must be one.
          • 4y ago
  • deleted 4y ago
    [deleted]
• gizmo686 4y ago
  The higher level thing to notice is that Windows is a second class platform for much of the software world. As such, it is in a position where it needs to bend the knee for compatibility with the dominant platform if they want it to be an active player in the larger ecosystem. In the case of symlinks, the hard part is already done, to the point where it is a toggle that has already been implemented, the UX of enabling it is just bad.
  • pjmlp 4y ago
    For game developers and GUI applications it is first class. Apparently being the best in symlinks hasn't made a difference in the Year of Desktop Linux.
  • jeroenhd 4y ago
    Both soft links and hard links, as well as directory junctions, have been possible in Windows since Windows XP (though soft links have only been available since the release of Windows Vista 18 years ago). In fact, hard links are essential parts of Microsoft's solution to the DLL hell problem without wasting gigabytes of space. 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-protection/security-policy-settings/create-symbolic-links https://docs.microsoft.com/en-us/windows/security/threat-pro... [2]: https://blogs.windows.com/windowsdeveloper/2016/12/02/symlinks-windows-10/ https://blogs.windows.com/windowsdeveloper/2016/12/02/symlin...
• binarycrusader 4y ago
  You don't have to enable Developer Mode to enable symlink creation. Administrators have the right to by default and non-administrator users can get this by enabling the documented policy: https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/create-symbolic-links 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/symlinks-windows-10/ https://blogs.windows.com/windowsdeveloper/2016/12/02/symlin...
• nicoburns 4y ago
  Projects don’t use symlinks because they aren’t supported on windows.
  • pjmlp 4y ago
    https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/mklink https://docs.microsoft.com/en-us/windows-server/administrati...
    • Dylan16807 4y ago
      The command won't help when you don't have the permissions. Or do you just want it to be phrased "not supported for users on normally configured systems"? There, then.
      • pjmlp 4y ago
        Well, time to learn about /J flag.
        • Dylan16807 4y ago
          Even if we pretend that's a symlink, it only works for directories, not files.
          • pjmlp 4y ago
            We moved from Windows doesn't do it, it does but isn't available to non admins, it is but non admins can't do files,.... Yep.
            • Dylan16807 4y ago
              We started at "not supported", talking about making symlinks inside projects. 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.
• pjmlp 4y ago
  Nope, since XP that you can use mklink, and before there were Technet utilities for the same purpose. However using symlinks just isn't a thing in the Windows culture, people use at most Shell shortcuts.
• orwin 4y ago
  No, they're not really. And IIS is not that bad either. My main gripe with windows and why i won't develop on it anymore is simple that their system is too complex. I suppose this is the gripe of the article author as well tbh. 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.