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

51–60 of 129 posts

Re: The tale of aux.c

#51

Post by captainmuon »

colejohnson66 wrote: post #45
flukus wrote: post #17

Earlier quoted context omitted.

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.

Or they could just create a registry flag that enables the backwards compatible behavior. Then all default installs don't have the "bug", while those that need it can enable it.

They could probably make the new behavior opt-in in the application manifest.

Without a manifest, you'll see pre-XP common controls, and GetVersion will return an old version, so every modern application has it anyway.

Re: The tale of aux.c

#52

Post by mypalmike »

tedunangst wrote: post #25
spullara wrote: post #15

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 rando…

Lesson: always zero pad.

00Good Advice

Re: The tale of aux.c

#53

Post by [deleted] »

tasty_freeze wrote: post #42

This is an entirely different mechanism, but was bitten not long ago by a surprising feature of the C++ language. It was as surprising to me as I imagine saving a file to aux.c would be. I was working on a C++ program, editing, compiling, debugging as one does. After a while, my efforts to compile were stymied due to a flood of weird compiler errors that didn't make sense. After rewinding recent changes to a point wh…

[deleted]

Re: The tale of aux.c

#54

Post by [deleted] »

drfuchs wrote: post #31

So, you smug Linux guys think it can't happen to you? Well, before you get off my lawn, let me tell you a story... Early versions of FrameMaker kept all resource files (internationalized strings, dialog box layouts, etc.) in the two subdirectories .../FrameMaker/Resources/{Unix,Core} (the first one for the Unix platform-specific resources, and the second for the cross-platform ones also used by the Mac and Windows po…

[deleted]

Re: The tale of aux.c

#55

Post by kieranelby »

flukus wrote: post #47
drfuchs wrote: post #37

Earlier quoted context omitted.

Ok, "unix-derivative" if you prefer. FWIW, it actually happened on SunOS or maybe HP-UX, and it was before Linux existed.

But it could have just as easily been a windows batch file, it's not related to the OS at all.

Well, apart from the fact that UNIX-like systems have traditionally dumped core files in programs' working directories if they crash, so needing a script to clean them up.

Linux still does, though many distros set ulimit or /proc/sys/kernel/core_pattern to disable it.

Re: The tale of aux.c

#56

Post by dfox »

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.

I would not be that surprised if even in this year's version of some niche CADs the most sane way to print the drawing in correct scale on DesignJet is to export the document as 'PRN.HPG' or something similar.

Re: The tale of aux.c

#57

Post by dom0 »

colejohnson66 wrote: post #46
richard_todd wrote: post #36

I wonder if the restricted names are still with us in ReFS? I don't have one handy to check it on, but it seems like if there were ever a good time to break backwards-compatibiliy, ReFS would be it.

The restriction isn't in the filesystem. You can mount an NTFS filesystem on a Linux box, create a file called "aux.c", then mount that filesystem on Windows. See also: https://news.ycombinator.com/item?id=15335209 and https://news.ycombinator.com/item?id=15335474

With default mount options you can even create files/folders named foo\bar.

Re: The tale of aux.c

#58

Post by emerged »

sophacles wrote: post #30
JosephRedfern wrote: post #19

What happens if you create a file called aux.c under a different OS, and then mount the drive on Windows?

This is the type of question that leads to new classes of exploit... well thought!

Except it's one of the first things each of the thousands (likely more) of professional and hobbyist hackers have already tried after learning about this particular OS quirk

Re: The tale of aux.c

#59

Post by jstanley »

condescendence wrote: post #24

>But nowadays, people confuse Microsoft Windows, the successor to DOS, with a Unix operating system, and want to run mailx on it. ...huh >If you want to use mailx, there is the technically and morally sane option of using a free Unix implementation. I mean it's really not that hard to release a Windows compatible version. You change a single file name? This just sounds like throwing gas on the flame war that is unix…

It was written in 2007. There was much greater tension between Microsoft and free software at that time.

Re: The tale of aux.c

#60

Post by gkya »

drfuchs wrote: post #41
jlgaddis wrote: post #38

Earlier quoted context omitted.

While an interesting story, this is more of a self-imposed customer screw-up and not quite the same thing, IMO.

A more direct (though fictional) illustration that Unix also has reserved file names that you'd better avoid: "I was writing a novel about digging to the center of the Earth, entitled "core". One day I was running some program that crashed, and my novel turned into a bunch of binary gibberish." Or how about: "My video of my kid's first at-bat, in a file I named a.out, got mysteriously clobbered when I took my first p…

You don't really put videos into a program's source tree. Also I don't think any modern Unix-like OS would overweite a file with a core dump no matter what is the name, and doubt that ancient versions did so too. Having the same set of device files under every directory is quite a different thing.
Post reply on HN