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

41–50 of 129 posts

Re: The tale of aux.c

#41

Post by drfuchs »

jlgaddis wrote: post #38
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…

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 programming class." These are more insidious than the MSDOS examples, which at least fail right away.

Re: The tale of aux.c

#42

Post by tasty_freeze »

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 where I knew it used to compile, it still refused to compile.

Finally I figured it out. During debugging, I created two copies of log file, one called "old" and one called "new". Somewhere in an include file (which probably included other files, etc), there was a statement "#include ". Rather that picking up the library source code, it tried to interpolate the contents of the local file "new" during the compile phase.

Re: The tale of aux.c

#43

Post by Theodores »

I came from a BBC Micro background and found MS-DOS to be a step backwards from what I knew. I couldn't believe how naff MS-DOS was and how lazy the coders must have been to make it so primitive. I also found PC vendors to be lazy too, it wasn't as if any of them made an effort to do any code to improve on matters, they just shoved the same old MS-DOS in the box.

What I had not realised before reading this article was that the file system was as flat as Acorn's ADFS, i.e. no hierarchy. How this joke of a product came to take over the world and take us from networked computing to standalone 'personal computing' was a tragedy, holding computing back 'decades' rather than enabling a better world.

Re: The tale of aux.c

#44

Post by TheDong »

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…

They are less insidious by far. You're really reaching for threads here.

The first, `core`, isn't relevant. `/proc/sys/kernel/core_pattern` configures that value, and by default it's named "core.$PID" nowadays.

That's far better than windows' wart since it's configurable, disableable, etc.

Your second example is even more contrived. If you run a tool which writes files, of course it can overwrite files. I don't complain that in windows when I type "copy foo bar" my "bar" file is overwritten by "foo".

In the same way, someone who voluntarily runs "gcc x.c" or "cat > foo" should not be surprised when "a.out" and "foo" respectively are overwritten.

There's a massive difference between an unconfigurable gotcha based on a filename and an explicit action which writes a file.

Re: The tale of aux.c

#45

Post by colejohnson66 »

flukus wrote: post #17
kevin_thibedeau wrote: post #16

Earlier quoted context omitted.

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.

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.

Re: The tale of aux.c

#46

Post by colejohnson66 »

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

Re: The tale of aux.c

#47

Post by flukus »

drfuchs wrote: post #37
hossbeast wrote: post #32

Earlier quoted context omitted.

How is this specific to Linux?

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.

Re: The tale of aux.c

#48

Post by feelin_googley »

If I had to guess I would bet that none of the commenters in this thread have ever used the Heirloom version of "mailx", and some have never used, or would ever want to use, the BSD mailx either.

It is a shame because I think Mr. Ritter deserves more recognition for his work.

IMHO, some of his versions are real improvements over the BSD ones, e.g., troff (doctools) and nailx.

I for one am very thankful for the Heirloom Project and very glad to see it live on.

Re: The tale of aux.c

#49

Post by pjmlp »

Grom_PE wrote: post #13

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

It was finally fixed on Windows 10.

Re: The tale of aux.c

#50

Post by Triave »

Theodores wrote: post #43

I came from a BBC Micro background and found MS-DOS to be a step backwards from what I knew. I couldn't believe how naff MS-DOS was and how lazy the coders must have been to make it so primitive. I also found PC vendors to be lazy too, it wasn't as if any of them made an effort to do any code to improve on matters, they just shoved the same old MS-DOS in the box. What I had not realised before reading this article wa…

ADFS allowed directories, but used "." as the separator, giving you paths like "Letters.Memo1".

Were you thinking of DFS?

Post reply on HN