Windows is, for better or worse, fiercely proud of its backwards compatibility. So it's not so much a stupid Windows design choice as a 'stupid' DOS 1.0 design choice (and not even so much a choice as simply a quirk of how the DOS 1.0 file system worked) that Windows doesn't want to break backwards comparability with.
I agree with parent that it's a bit crazy; but I wouldn't be as critical. to your point; presumably even if they dropped DOS support something between DOS and now likely relies on that. It's a fine line.
Stupid design choices on Windows are always justified by "backwards compatibility". What I don't understand is why an app for DOS doesn't work on Windows 10. Or a lot of Windows XP software that doesn't work anymore. Heck, anyone remember of Windows Vista and all the mess with "Compatibility Mode" that never worked?
Hehe, Linux (and Unix in general, I guess) is just a bundle of text files and C programs, held together by shell scripts and eternal vigilance. It's very impressive and very disappointing at the same time...
People could also stop using CreateFile without a \\? prefix and all the problems would go away. There's not even a MAX_PATH limit on any NT based Windows version if you do that.
Except that only works for absolute paths. And then also changes other semantics that you might expect to be there - e.g. it disables handling of .. and . to mean parent and current directory (which is valid even in absolute paths, and often useful).
It comes down to tutorials a lot of the time - does any tutorial in C, C#, Python, whatever mention that you should probably refer to paths in Windows like that?
C# can't because .NET has outright banned the usage. But now the length restriction has been lifted, at least in .NET Core. I think you still need Windows 10 with path length limitation disabled for the full .NET Framework. It's actually a bit confusing because the limitation was lifted in .NET Core first by using \\? prefix internally, but then not long after Windows 10 introduced the ability to remove the limitation for the api without the prefix, but it must be enabled by group policy or registry patch...
Anyways, it shouldn't really have mattered that Microsoft didn't care much for this for a long time. If everybody else had just been using the prefix since Windows XP came out then Microsoft would soon have been forced to change their own software as well.
For example with Python and non-MS C (e.g. clang and gcc on mingw), they should simply have made the standard libraries implement the file api using the prefix. Of course if you have a need to call CreateFile directly you would still be on your own, but if everything else created files you couldn't interact with then you would probably fix the problem.
To me, it sounds more like a problem with Rust that a single misnamed package could bring down the whole system. It's essentially a SQL injection attack (without the SQL).
Yep, just not allowing (directly) user controlled file names seems ideal. Maybe just hash the crate names and use the hash as a file name? No more silly restrictions due to platforms. Eliminates issues with some file systems having a length limit too.