Please rename aux.py | Hacker News Reader

Please rename aux.py

github.com

71 pointsBostonian34 comments

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.

Microsoft still recommends avoiding those file names. https://docs.microsoft.com/en-us/windows/win32/fileio/naming...

Back in the 90s we had novell intranetware, and internet explorer on our computer room machines which opened up on login.

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.

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.

IIRC windows 9x would instantly bluescreen if you tried to open c:\con\con , probably because of a bug in the filesystem driver.

These are old CP/M filenames that DOS reserved for cross-compatibility. They "exist" in every single directory, as CP/M was a directory-less OS.

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.

Why only Win32 — Azure Kubernetes had this limitation under some circumstances, even a few years ago[1]. Anyone know if this issue is still present?

[1] https://news.ycombinator.com/item?id=17703371

What were the PRN and AUX files used for?

PRN was for the printer.

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.

AUX is just a synonym for COM1, i.e. first serial port in DOS/Windows.

Why You Can't Name A File CON In Windows -- https://www.youtube.com/watch?v=bC6tngl0PTI

The official docs appear to be https://support.microsoft.com/en-us/office/restrictions-and-...

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.

Hello fellow CP/M and MP/M users.

The ghosts of the past, they never go quiet.

Please fix Microsoft OneDrive to allow customers’ choice of file names.

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.

> Win32 on the other had usually caps everything at 260 total (MAX_FILE_LIMIT).

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...

Doh! I should have got that. I should not have messed that one up.

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.

In general it's a mess.

The problem is not OneDrive but Windows and is not easily fixable without breaking backwards compatibility.

Then they are not trying hard enough

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?

What's your point with 9 vs 10? It's just a marketing naming decision.

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

There was no big downside to skipping 9, so why not do that.

Make a decade-long transition plan, I don't care. As long as there is a plan.

Design stuff like this can cause a lot of problems, when you just "fix" them. Just ask Windows enterprise customers how printing has been lately have.

Umm, just mangle it in the storage layer?

CP/M 80 and its quirks proving it was a real solid and influential OS :clap:

Reply on news.ycombinator.com