Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The tale of aux.c

heirloom.sourceforge.net

Post reply on HN
Print view View original

11–20 of 129 posts

Re: The tale of aux.c

#11

Post by breadbox »

trothamel wrote: post #8

Even if Microsoft keeps this behavior, I'm surprised they don't modify it to check the filename extension. It's one thing to change a device like CON that people might expect to exist, but it seems like not distinguishing CON and con.c is just asking for trouble.

Possibly. On the other hand, you're talking about changing behavior that's been in place for 35 years. It's more than a little late to garner any benefit from changing it. And the risk that you'll actually break an existing program somewhere is certainly small but probably not zero.

Re: The tale of aux.c

#13

Post by Grom_PE »

On Windows, paths can be accessed with \\?\ prefix:

    mkdir \\?\V:\con
    notepad \\?\V:\con\aux.txt
This avoids reserved filenames as well as 260-character length restriction. But many programs that try to do any path processing fail after seeing an unexpected prefix, even File Open dialog (on Win7 at least).

Re: The tale of aux.c

#14

Post by ploxiln »

dfox wrote: post #10
trothamel wrote: post #8

Even if Microsoft keeps this behavior, I'm surprised they don't modify it to check the filename extension. It's one thing to change a device like CON that people might expect to exist, but it seems like not distinguishing CON and con.c is just asking for trouble.

That behavior is intentional and is workaround for programs that does not let user change file extension on saving.

The funny part is, that is not the purpose at all any more. It was probably only for a handful of years that this trick was needed to "trick" programs which thought they were saving a normal file and forcing the correct extension to actually use a printer or serial port. No one has used a printer or serial port by File -> Save As to "lpt.txt" in decades!

Now it's just because some code hidden away under 10s of layers a millions of lines in some obscure line-of-business applications is accidentally dependent on this quirk and "it works now" and no one will ever fix it.

Re: The tale of aux.c

#15

Post by spullara »

In 1991 I was working at a place with a Novell Netware network. I decided to make a system that would execute remote commands by writing them to a shared directory and other machines would see the files and execute the commands. I named those files COMXXXXX.TXT where the X's were a random number (yeah, that was a bad idea). Every few days the system would hang and stop working. I finally narrowed it down to the random number being 1-9 that would correspond to the serial ports on the machine and it would then hang.

Re: The tale of aux.c

#16

Post by kevin_thibedeau »

ploxiln wrote: post #14
dfox wrote: post #10

Earlier quoted context omitted.

That behavior is intentional and is workaround for programs that does not let user change file extension on saving.

The funny part is, that is not the purpose at all any more. It was probably only for a handful of years that this trick was needed to "trick" programs which thought they were saving a normal file and forcing the correct extension to actually use a printer or serial port. No one has used a printer or serial port by File -> Save As to "lpt.txt" in decades! Now it's just because some code hidden away under 10s of layers…

This isn't an issue for contemporary human facing UIs. Somewhere there is guaranteed to be a crusty POS system still in use that is sending receipt data to LPT.TXT or AUX.TXT.

Re: The tale of aux.c

#17

Post by flukus »

kevin_thibedeau wrote: post #16
ploxiln wrote: post #14

Earlier quoted context omitted.

The funny part is, that is not the purpose at all any more. It was probably only for a handful of years that this trick was needed to "trick" programs which thought they were saving a normal file and forcing the correct extension to actually use a printer or serial port. No one has used a printer or serial port by File -> Save As to "lpt.txt" in decades! Now it's just because some code hidden away under 10s of layers…

This isn't an issue for contemporary human facing UIs. Somewhere there is guaranteed to be a crusty POS system still in use that is sending receipt data to LPT.TXT or AUX.TXT.

They could remove it in a new version of windows, that crusty POS system is going to be doing a lot of testing before they upgrade the version of windows it's running on. Even more likely is that they'll never upgrade from whatever ancient version they're using so it won't affect anyone.

I think they just keep it because it feeds into the backwards compatibility myth that MS has built up.

Re: The tale of aux.c

#18

Post by russellbeattie »

tyingq wrote: post #9
DiabloD3 wrote: post #7

Earlier quoted context omitted.

It doesn't even make sense to hold this position. Aux.c isn't even a usefully descriptive name for a file you'd find in a mua.

A legacy requirement to not ever have any files with a basename of CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, or LPT9 doesn't make sense either :)

I was wondering what the full list was. Thanks!

Re: The tale of aux.c

#20

Post by loeg »

pcwalton wrote: post #2

We ran into this issue in Servo too. https://github.com/servo/servo/issues/1226

The pirate scene occasionally hits this as well (copies of the film "Con Air" which would be named "Con.Air." by convention were instead named "Con_.Air" or "Con_Air" etc. All thanks to the legacy CON device.
Post reply on HN