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.

Yak shaving.

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.

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

That would be for removing the 260 character limit, not for enabling of symlinks.

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.

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.

A lot more tends to be world-writable in Windows, for starters.

It does support them, mklink.

https://docs.microsoft.com/en-us/windows-server/administrati...

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.

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.

That's exactly it. Windows developers know NTFS has Symbolic Links https://docs.microsoft.com/en-us/windows/win32/fileio/creati...

What's the standard for being an "actual Windows user"?

Asking because I doubt e.g. my mom knows that NTFS has symlinks.

Is she a Windows developer?

https://docs.microsoft.com/en-us/windows-server/administrati...

The developers who complained to me about this are Windows developers regularly.

One is even a professional AAA DirectX gamedev.

Apparently not professional enough to know a feature as old as Windows 2000.

Egads, if the parent post wasn't edited, then I misread it. Sorry about the confusion.

It was edited.

> What's the standard for being an "actual Windows user"?

I think you misread that line.

Their message originally read "Actual Windows developers know NTFS has Symbolic Links"

Would anyone like to explain their downvotes?

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?

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.

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.

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.

NTFS is the only filesystem that matters for Windows developers.