Windows does actually have symlinks but I don't think I've ever seen anything actually use them, and I don't myself because it smells of interop issues with other windows apps.
Even to this day Windows has all kinds of problems around long file paths in its ecosystem.
> 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".
The 260 character limit is just a Windows problem. See my other comment in this subthread for a summary of the eldritch horror in question. The tl;dr is that backwards compatibility is a helluva drug.
It’s a Windows problem. There’s still, to this day, a 259-character limit on path length in the Win32 API unless the OS has been configured to support long paths and the application uses the correct subset of Windows APIs. For example if you use ‘CreateFileA’, you’re stuck with the limit no matter what.
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.
Windows supports it but git disables creating symlinks by default.
> 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.
Fine if you don't need to git checkout the repo on Windows :)
Just .gitignore CLAUDE.md and handle it locally. Checking in a symlink would be weird.
Wow, still not there yet. After all these years.
Windows does actually have symlinks but I don't think I've ever seen anything actually use them, and I don't myself because it smells of interop issues with other windows apps.
Even to this day Windows has all kinds of problems around long file paths in its ecosystem.
> 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".
It’s not just a windows problem. File systems are an absolute disaster across all platforms. David Wheeler has a lovely article on the topic: https://dwheeler.com/essays/fixing-unix-linux-filenames.html
The 260 character limit is just a Windows problem. See my other comment in this subthread for a summary of the eldritch horror in question. The tl;dr is that backwards compatibility is a helluva drug.
The worst offenders I've found are powershell and .Net related stuff.
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.
It’s a Windows problem. There’s still, to this day, a 259-character limit on path length in the Win32 API unless the OS has been configured to support long paths and the application uses the correct subset of Windows APIs. For example if you use ‘CreateFileA’, you’re stuck with the limit no matter what.
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.
Thanks for the explanation! This is indeed consistent with my observations.
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?
I'm surprised Git and/or Windows don't support symlinks?
Windows supports it but git disables creating symlinks by default.
> 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.
See: https://gitforwindows.org/symbolic-links.html
Yeah this is why I don't trust people saying devex is fixed on Windows now. Still doesn't properly clone git repos.
Windows does mklink. Not surprised with git.
are you though?
oh god. sorry.
you'll need to wrap that in a `find` because of nested instruction files