Re: Have they fixed the decades old bug in File Explorer ?
"NTFS parser can not handle it"
NTFS itself handles it just fine. The system path parser that understands how to resolve ".", ".." and other oddities, as well as transforming forward slashes into backslashes, and also converting relative paths into absolute ones? No, it can't handle it on ANY file system.
Using the APIs correctly allows your program to handle it just fine.
Specifically, taking *just* the example of CreateFile (which *also* opens existing files, but ...):
* CreateFileA (MBCS version that works with "narrow" characters) cannot do it.
* CreateFileW ("Unicode" or "Wide character" version) *can* do it.
* Specifically, your filename must be fully parsed (so the *system* parser - it has nothing to do with NTFS as such - cannot handle it, you are right), with no elements being "." or "..", and all separators being backslashes and no stars or question marks, AND it must be an absolute path.
* Then you must prefix the fully-parsed absolute path as described above with backslash backslash dot backslash. And yes, that means that if the absolute path is a UNC path, you end up with three backslashes in a row.
If you do all that, you can access paths up to 32K-1 wide characters long. It's annoying, but overall the main annoyance, from the programming point of view, is having to work in wide characters.
That Explorer doesn't use these APIs like this *could* be regarded as lazy programming, or it could be regarded as a deliberate decision to protect the user from feebleminded software that doesn't know how to handle super-long paths. (Notably, I'm not sure how CreateProcess and ShellExecute handle these paths.)
Biting the hand that feeds IT
