As far as I know you can bypass that with a \\?\ prefix in the path. This tells the API that your path is a full NT file path, similarly the devices are mapped into \\.\ . Of course many tools on windows were not aware of that, so anyone trying to delete "C:/con/con" would run into the issue that they needed a tool which would delete "\\?\C:\con\con" instead.

To be honest, I don't know. This is nearly 20 years ago now.

I assume the FTP server created the directories using a different file-system API call than Windows Explorer.

Here's a post by someone who found one of these directory structures on his FTP server back in 2003: http://www.informit.com/articles/article.aspx?p=31278

My guess is that there's 2 APIs to access files, a user mode API and a kernel mode API, and this special casing is only available in the user mode one. If the FTP server uses the kernel API it bypasses the special case file handling.

The guy forgot to try to log into the ftp server itself to delete the files. After all, if the ftpd program used the correct APIs to create the directories and files, it would probably also use the right ones to delete them.

Judging by how the article was written, that probably wouldn't have helped him. You couldn't delete these directories directly, but rather had to delete the nested "unnamed" directory: “/path/to/COM1/ /“, which is also how you would create the directories in the first place. Usually, the tag-directory would also go along with a list of directories explaining that you should not create "undeletable" directories on NT-based servers, as that would annoy the admin and might cause them to remove anonymous access. You were only supposed to create large mazes of directories to prevent other random anonymous users from finding and deleting your files.

There has always been a discrepancy in capability between win32 file-related APIs and GUI tools. Even in Windows 10, it is possible to use the APIs (as simply as through, say, git bash) to create files and directories inaccessible (even for deletion) to Explorer.

Since the special filenames were handled at the OS level, any crash would have required the OS to mount the FTP directories. I don't think Windows' FTP program ever mounted anything, meaning the directories were handled by the program and not by the OS. When you copied anything to your local Windows machine, the file would automatically be copied to a directory with a safe name rather than mimicking the directory hierarchy from the remote server.