> Short version: there is no exact equivalent for POSIX symlinks on Windows, and the closest thing is unavailable for non-admins by default unless Developer Mode is enabled and a relatively recent Windows 10 version is used. Therefore, symlink emulation support is only turned on by default when that scenario is detected. Support can be enabled by the user, via the core.symlinks=true config setting.
Even to this day Windows has all kinds of problems around long file paths in its ecosystem.
To this day I don't know if it's a Windows problem or a Python problem, because I never encountered this - and never realized this problem exists - except for some random Python code whose docs tell me to set some registry value because of "long paths issue".
You can have all the right flags enabled, then unexpectedly you'll run some commandlet and get a path too long error.
Now if your on W11/W25 and the lastest PS it might all work, but W16 and PS versions between now and then had all kinds of things pop up.
There’s no problem with Python in general. The registry value LongPathsEnabled, which is probably the one you were asked to set, affects the entire Windows system.
However, there’s also an older workaround that allows programs to use “extended paths” even if that setting is off, by prefixing path strings with “\\?\”. So applications using that workaround can use long paths no matter how Windows is configured. But Python doesn’t use the workaround, it uses the modern APIs and if you want long paths, you need to configure the underlying Windows system to enable it.
But it brings me to two follow-up questions:
1) What is that registry switch even doing, if the problem can be solved with just setting it?
2) Why is Python not using the workaround like ~everyone else?