So, all that text to tell people he is refusing to rename a single file? :-P<p>I encountered that issue a few times in the past, most recently when a couple of years ago i was writing the console support for my 3d game engine and made two files called `con.c` and `con.h`, checked them in to version control and then at some point (much) later synced it on the Windows side. Fossil (the VCS i use) simply skipped that file (maybe it complained? i don't remember, but the files weren't created) and when i tried to build the engine it didn't work - i thought that i forgot to add the files, rebooted to Linux, forced a re-add, back to Windows and nothing again.<p>Eventually it clicked that "con" is a bad word in Windows filesystems, so i simply renamed the files to `csl.c` and `csl.h` :-P. I found this a bit irritating because my naming convention follows a mostly rigid pattern where `xxx_` prefixed functions will always recide on `xxx.c/h` (or `xxx_yyy.c/h` where yyy is a subsystem or specialization) and i really prefer the `con_` prefix to the `csl_` one. So far i've kept the `con_` prefix and made a special note for that in the readme file where i explain the naming conventions, but every time i have to use or work with that part of the engine i feel the irritation :-P.
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...<p>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 ports). We had hundreds of happy customers, and had been shipping for 4 years or more.<p>But one new customer was calling in a panic. They'd installed the product, and it would work fine, but the next morning, it wouldn't even start up, and they had to re-install it. And then it would break again over night. After much pulling of hair and gnashing of teeth, it turns out that due to some other flakey product they were running, they had previously instituted a nightly cron job that ran around removing any core files it could find (since they were large and wasteful of precious disk space back in the day). And the knucklehead who wrote the script had it do a case-insensitive match on "core" <i>and</i> had it essentially do a "rm -rf" even though no true core file could be a directory. So, every night, our Core resource directory was blown away.<p>We actually had to change the product, as this was a big, important customer, and they outright refused to fix their cron script. Never had this problem on the Windows and Mac ports.
On Windows, paths can be accessed with \\?\ prefix:<p><pre><code> mkdir \\?\V:\con
notepad \\?\V:\con\aux.txt
</code></pre>
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).
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.
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.<p>It is a shame because I think Mr. Ritter deserves more recognition for his work.<p>IMHO, some of his versions are real improvements over the BSD ones, e.g., troff (doctools) and nailx.<p>I for one am very thankful for the Heirloom Project and very glad to see it live on.
We ran into this issue in Servo too. <a href="https://github.com/servo/servo/issues/1226" rel="nofollow">https://github.com/servo/servo/issues/1226</a>
>But nowadays, people confuse Microsoft Windows, the successor to DOS, with a Unix operating system, and want to run mailx on it.<p>...huh<p>>If you want to use mailx, there is the technically and morally sane option of using a free Unix implementation.<p>I mean it's really not that hard to release a Windows compatible version. You change a single file name?<p>This just sounds like throwing gas on the flame war that is unix vs windows.
Is this when I get to complain about operating systems that allow spaces in filenames which also have a shell language that makes it difficult to use those files?
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.
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.<p>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.<p>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 <new>". Rather that picking up the library source code, it tried to interpolate the contents of the local file "new" during the compile phase.
See also <a href="https://news.ycombinator.com/item?id=12129647" rel="nofollow">https://news.ycombinator.com/item?id=12129647</a> "Git for Windows accidentally creates NTFS alternate data streams"
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.<p>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.
Does anyone remember Basic-4 systems?<p>I transferred several programs, in those days and on that system with a maximum of six characters for the name, from one machine to another via magtape. One was named "CR" (customer report or credit report, who knows). It disappeared on the new system because it was mistaken for the Card Reader.
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.