This is almost certainly due to a windows limitation, which is in turn caused by compatibility for a DOS hack where a bunch of devices were visible through special file names. CON is the more famous one of those.
Worse: back in the day, you could type raw HTML into AOL Instant Messenger. Notably, being able to construct a link with whatever address you pleased, including `file://c:\con\con`.
Not just that, AOL allowed playing sound files from within a chat room. If a user sent `{s gotmail`, it would play the `gotmail.wav` file on the computer of each person currently in the chat room. So, sending `{s /con/con` or `{s /aux/aux` to that chat would instantly crash the computer of everyone in the chat, causing a BSoD. It was great fun if you were an obnoxious kid, and generally super frustrating for anyone trying to chat.
There was something similar with popular irc clients on windows in the late 90s early 2000s. There was a direct file transfer mechanism called dcc. If you forged a request for con/aux device files you could send instructions to the person's printer or modem and do all sorts of interesting mischief.
AUX is for "auxiliary" (aka "misc."/"other") device - i.e. any other bit of unspecified random hardware you'd managed to hook up with a custom driver by yourself.
This exact issue bit me in the arse at my old job when I created a directory called Aux in one of our git repositories on my Linux machine and suddenly nobody running Windows could pull from it without a fairly cryptic error. It's weird to think all that debugging was caused by a decision made back in the '70s for CP/M which eventually made its way into Windows via DOS.
That may be true for some things, but for example imagine being on the core Windows team in the early 2010s working on the next version of Windows (Windows 10). Given all the baggage of Windows and how committed it is to backwards compatibility, are you going to decide to name the next version of Windows "Windows 9" and deal with the endless deluge of your customer's bemoaning, or are you going to save everyone a lot of headache and just go straight to 10?
This was technical issue.
Windows 9 had issue that a lot of software had checks if this is windows 95/98 by comparing only windows 9 part, this caused in testing that some software was throwing errors on windows 9, that you need something like windows xp
Windows actually has always had a fairly large number of restrictions on filenames and folders, what is really frustrating now is that the impact and restrictions aren't universally validated. For instance you can create a folder that's name ends in a space in most IO libs available on windows, but many file and directory access libs will hard crash on this.
They really need to revamp the whole thing, and their efforts in more modern OSes that attempt to virtualizes each apps access seems like a place this would have been a priority, and yet a poorly named file or folder can still cause a Crash to desktop.
I recalled some of those issues are related to Explorer.exe. For example, there is a restriction on the path characters, I believe it is 256 characters limit. This includes the directory path that the file is located in. This is the issue with Explorer.exe (I think it was due to Explorer is 32-bit), Windows and the file system does not have this limitation because it can manage them just fine. I remember years ago that I have several windows app that can open the file with absurdly long path name without issue (like IrfanView). If I tried to open the file directly from Explorer, it will refuse to load or it will spew out an error. The restriction was imposed because of Explorer limitation. Now, Explorer can handle the with the long path but it has to be enabled in the registry.
260 is the typical limit. NTFS allows for 65535 per filename and I think up to 65535 deep on directories (I could be wrong on the second one). Win32 on the other had usually caps everything at 260 total (MAX_FILE_LIMIT). Most of the docs and examples out there use that. I would bet that it is some sort of FAT limitation.
This can be annoying if you move a drive between differing OS's and the NTFS bit on the other side does interesting things. NTFS is also case sensitive. But the win32 layer 'hides' it mostly, there is a flag to turn it on. Unless you do something like write from a linux box and you can end up with 2 files named the 'same' but different case. It is also possible to trick windows into doing it but it is tougher.
It's not limited to explorer, for instance attempting to open excel document, whose path is too long can cause odd errors, often claiming permissions errors.
You also have issues where something can be opened with a long path but then the saving fails because it can't write to the location.
The block on _vti_ sounds wonderful, is there really Frontpage Extensions stuff still somewhere deep the bowels of OneDrive that somehow makes it unsafe?
_vti_ is a SharePoint thing. It does have its origins in FrontPage but the folder naming carried over into SharePoint and the functionality has morphed somewhat.
34 comments
[ 3.2 ms ] story [ 75.2 ms ] threadMicrosoft still recommends avoiding those file names. https://docs.microsoft.com/en-us/windows/win32/fileio/naming...
One IT lesson, I changed the front page it opened to something like "<img src='c://con/con'>", very amusing :D
Nowadays I'd probably be arrested.
AUX is for "auxiliary" (aka "misc."/"other") device - i.e. any other bit of unspecified random hardware you'd managed to hook up with a custom driver by yourself.
[1] https://news.ycombinator.com/item?id=17703371
Make a decade-long transition plan, I don't care. As long as there is a plan.
They really need to revamp the whole thing, and their efforts in more modern OSes that attempt to virtualizes each apps access seems like a place this would have been a priority, and yet a poorly named file or folder can still cause a Crash to desktop.
This can be annoying if you move a drive between differing OS's and the NTFS bit on the other side does interesting things. NTFS is also case sensitive. But the win32 layer 'hides' it mostly, there is a flag to turn it on. Unless you do something like write from a linux box and you can end up with 2 files named the 'same' but different case. It is also possible to trick windows into doing it but it is tougher.
Nitpick: It’s MAX_PATH :) Also, there is a way around the limitation: prefix all (absolute) file paths with \\?\
https://docs.microsoft.com/en-us/windows/win32/fileio/maximu...
You also have issues where something can be opened with a long path but then the saving fails because it can't write to the location.
In general it's a mess.