How a 1974 bug still bites Win10 and Azure users

A file naming decision harkening back to the earliest days of personal computing is still very much alive in Microsoft's Windows 10 and its Azure Functions serverless cloud code execution tool, much to the merriment of geeks old enough to remember the reasons for it.

Over the weekend, self-described software and hardware necromancer Foone shared a long and very detailed thread on Twitter about how he tried, and failed to copy a file from one USB solid state drive to another in Windows 10.

The file that Foone tried to copy was a C/C++ header file named aux.h. Mysteriously, the copy operation failed with an error message saying "the file AUX.H is too large for the destination file system". 

This despite aux.h being a only a minute 9.57 kilobytes in size.

Foone worked out that the culprit was the use of a file name that's deemed as special in Windows 10 - AUX - used to access specific parts of the computer hardware, such as printer and parallel and serial communications ports.

Often called "magical files", they are a convention with roots that go back to 1974 and the CP/M operating system which Bill Gates bought the rights to and which became the foundation of the Microsoft Disk Operating System or MS-DOS.

They remain in use today due to backwards compatibility with older versions of Windows.

Microsoft veteran Charlie Kindel tweeeted how the bug could've caused major problems with a precursor to the .NET coding framework.

The project that eventually became the .NET Framework was originally called COM3. I quickly realized this was a bad idea because of this bug. We then renamed it to COR (Common Object Runtime). https://t.co/13ho5Tgtdz

— Charlie Kindel (@ckindel) November 3, 2018

Aussie Microsoft Regional Director Troy Hunt was also bitten by the now-ancient bug.

He was scratching his head trying to figure out what was causing a "Oh no! Catastrophic error" message to appear on his data breach website haveibeenpwned.com.

The message appeared when users searched for an email address starting with "con." on haveibeenpwned.com which uses Microsoft's Azure Functions Serverless tool for code execution.

Here's a fun one for the .NET and @AzureFunctions folks:

HTTP triggered function with a route like this: "mypath/{myparam}"

Whenever the param starts with "con." the route isn't found. Only happens in Azure, never locally. "com." is fine, "don." is fine. Ideas?

— Troy Hunt (@troyhunt) November 5, 2018

Hunt was duly directed to Foone’s Twitter thread, which explained why searching for an email address such as “con.address@example.com” doesn’t work on certain Microsoft platforms as “con”, too, is a special file name.

The full list of troublesome file names for Windows 10 and Azure Functions according to Microsoft is:

CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9.

"Also avoid these names followed immediately by an extension; for example, NUL.txt is not recommended," Redmond warns.

Using the above special file names will cause problems for applications running on Windows-based operating systems for instance when they're used as part of website links, and the error messages are not clear on why things go wrong.

"So for now, it looks like people who have addresses such as con. or prn. or lpt1. aren't going to get haveibeenpwned results," Hunt said.

Hunt opened a ticket at Microsoft-embraced code repository Github, and it turns out there is a workaround configuration option that Hunt and other admins can use for .NET as per coding luminary Phil Haack's suggestion, to deal with the obscure 44-year old bug haunting users today.