A 'trick' used by the file-sharing community in order to hide their files on these anonymous FTP servers was to create some nested directories with these kind of keywords. The FTP server allowed you to create the directories as well as access them (if you knew the full path) but on Windows they would just cause errors or crashes if someone tried to access them. Combine that with the ability of creating directories with just spaces as names and you could hide quite a bit of stuff from the unsuspecting FTP server administrator.
The lab admin had disabled Ctrl+C and Ctrl+Break to keep folks from breaking out of the DOS-based login prompt to a C:\ prompt, but I somehow figured out that Alt+3 passed an equivalent character and had the same effect.
I once got yelled at for being “in the lab too much” by one of the teachers, but I never got in any trouble. I suspect the lab admin (a kind older programming and math teacher) knew what we were up to.
Figured out the default password scheme for teachers.
Found several teacher accounts that didn’t change their default password.
Teacher accounts could write to network drives when students couldn’t.
Put games like it, quake 2 and c&c ra2 on the network.
Lasted about six months.
A student I had confided in ratted me out.
I was no longer permitted to touch another school computer.
I failed every class that required me to use a school computer.
Despite the fact I brought my own laptop to school, they wouldn’t let me use it.
Formal education and I never got along after that.
I'm convinced that I would have had a more useful education if I had dropped out, moved to Silicon Valley, and lived out of a van working for minimum wage at a startup than if I had finished high school.
Unless your parents can and will sue, the public schools (SPIT) will do as they choose.
For a couple weeks the school was absolutely convinced my friend and I were responsible for taking a few computer labs in the district offline and claimed we created a virus.
Eventually our folks replaced At Ease with some other app, (Cyber something, control something? no idea) but they setup a hotkey to disable it which was nothing less than shift + K. That didn't last long at all, with Karla, Kyle, Keith, and Katie getting incredibly frustrated just trying to type their name.
It was used for broodwar mostly, this was around 1998
The only thing was that you had to access your own machines with an ftp client because of path tricks like this. (Or get a Linux box, and cross your fingers nobody would find yet another wuftpd buffer overflow)
wuftp was responsible for the popularization of format-string attacks, which were magical at the time.
We all knew about buffer-overflows, and when it was explained format-string attacks were obvious, but it was the first time I'd seen a genuinely new class of software attacks.
And then Microsoft got tired of it, and (IIRC starting with Windows XP SP2) locked it down. Now if you have a legitimate need to use DCOM (for instance, OPC-DA), you have to jump through a series of hoops.
I wonder if that was really the case in the early internet at an enterprise level. Did security take a backseat to functionality?
Shouldn't it have crashed, like the blue screen-causing <img src="C:/con/con">
I assume the FTP server created the directories using a different file-system API call than Windows Explorer.
Here's a post by someone who found one of these directory structures on his FTP server back in 2003:
Man, I remember doing this to find video game executables. Good times.
The reserved names are things like "COM" and "LPT" followed by a digit... or at least, a thing that Unicode recognises as a digit, so "COM²" is just as broken as "COM2".
This device remapping is done in the Win32 layer, not the NT kernel, so you can often use "verbatim path syntax" to bypass these hacks. So "C:\Temp\COM2.TXT" is a magic device, but "\\?\C:\Temp\COM2.TXT" is an ordinary file you can read or write without issue... until you try and look into C:\Temp with a program that doesn't use verbatim paths like Windows Explorer, and all hell breaks loose.
And to be honest I haven't found any significant search performance difference, compared to the indexed-search options.
Refer to the Enhanced Mode for Search Indexer section of that page.
This one caught me by surprise a few months ago when I helped out someone using Windows. I knew the files were there, but couldn't for the life of me find them. Turns out there was some search setting that prevented search to traverse all dirs... Wasted hours. In the end I googled how to search in Windows. Absolutely awful UX.
The taskbar is managed by Explorer.
There are many, many examples of similar (mis)features. Not sure why this particular one is getting so much attention. But yeah, if you know the history, it's not really surprising.
For anyone interested in this sort of software archeology, have a look at Raymond Chen's blog https://blogs.msdn.microsoft.com/oldnewthing/ which is full of this stuff. Very interesting reading.
That's a bug. It should say something closer to "The filename AUX.H is a reserved filename and can not be used by this system"
This file name is reserved for use by Windows. Choose another name and try again.
The disk full message is different, so my money is on an oddly formatted disk.
"Versions 2.x of MS-DOS provide the AVAILDEV CONFIG.SYS parameter that, if set to FALSE, makes these special names only active if prefixed with \DEV\, thus allowing ordinary files to be created with these names."
It's bizarre that once it became clear that this was going to be a problem (when harddisks and directories were introduced, or with Win95, or XP at the latest), they didn't decide to deprecate the stupid way and push everybody to use the sensible way.
You may have to support both ways for a while, but once you start supporting stupid ideas like this out of a need for backwards compatibility, it should be obvious that it'll never go away unless you make it go away. Maybe allow old software to run in QDOS-compatibility mode or something. It's just insane that this is still a real limitation in Win10.
> If a change results in user programs breaking, it's a bug in the kernel.
Reminds me of how many things broke when Windows started any kind of basic enforcement of read/write permissions (files, registry keys) in NT 4, then in 2000, then in XP, until I guess they gave up and created an abstracted API so that programs can trash all they want)
(Yes, I'm still bitter)
Back in the earliest days of Windows, I wanted a way to log some debug output, and there were not a lot of options. You could write to the AUX device, if you had a serial terminal attached.
So I figured I would write a device driver that redirected AUX output to the monochrome display, glass teletype style, while Windows ran on the color display.
Naturally, I named it AUX.SYS, with a source file called AUX.ASM.
Oops. That didn't work too well.
Eventually I figured out that I couldn't name any file AUX.anything.
I was going to call it AUXDRV.SYS instead, but then I thought it would be fun to use a name that sounded like AUX but wasn't spelled that way. So OX.SYS it was!
(Unless, in your dialect, you don’t pronounce 'orcs'and 'aux' in exactly the same way, as I do)
• “ox” /ɒks/
• “aux” /ɔːks/
• “orcs” /ɔɹks/
But hey, close enough for a pun anyway. My favourite rhymes and puns are those that work in any accent, but it’s a bit harder to come by one that’s not overused.
I had tidied up a script distribution that had been unloved for a while and got a bit out of hand. I'd been working at home on a Debian laptop, and committed my changes back to Subversion - one of which was to gather up and organise some auxiliary files into one neat and tidy directory. Naturally, since the script already had ./bin, ./lib and ./etc, I went with aux.
I came into work after the weekend to find my Windows-based colleagues, who were in the habit of checking out a single working copy of the entire repo, in full panic mode because "Subversion is broken, IT say we might have lost everything"...
These days I name aux directories 'etc'.
Windows git executable should be aware of OS limitations and should be able to work around them. Of course, Windows API should also fail to create invalid fs objects, so there's that...
Microsoft provide file system access which is not impacted by MAX_PATH and that is what git is using when it writes to the file system. If anything I think Microsoft should fix Explorer which they kind of have in Windows 10 with the long path option.
I don't know enough about why Microsoft still have the MAX_PATH problem. I am guessing, like most things Microsoft, it is due to legacy compatibility.
You can't work properly with that on the case-insensitive file systems on Windows and Mac.
NT has always supported case-insensitivity (at least somewhat) via a registry key.
With windows 10's linux subsystem, there is now a new command to make a _directory_ case sensitive.
I don't even blame MS nowadays. My idealism is weaker than my nostalgia. Without these hacks MS would probably die long ago. #worseisbetter
This is a 44 year old limitation.
"it's not a bug, it's a feature!"
A correctly working system would have simply said what limitation the user had hit.
I’m sure that in every file system there are names you can’t give a file - and if there aren’t then that problem is at least as big. For example if it’s possible to call files null, the empty string, “.”, the directory separator etc then that just creates more trouble. These are documented limitations and a non-buggy system will explain what limitation the user has hit.
Inconsistency such as differences beteeen file system and file explorer I could agree are borderline bugs at least in the UX sense. The user doesn’t see the file explorer UI and the file system as different things.
It's that failure to appreciate quality as a relationship which is the confusion.
Imagine being a developer of some windows software, and a QA person in your team notices that the software can't save to "aux.foo". You explain that this is a limitation of the Windows OS and you can't fix this. But QA insists that this is a "showstopper", and management agrees.
So you do a bit more research and you discover the work-around with the "\\?\" path prefix. You implement the "fix". Now QA discovers that they can save to "aux.foo", but windows explorer has weird issues with it, and they can't open the file in a text editor, and the file doesn't get backed up anymore, etc.
Wouldn't it have been better to accept the limitation instead of calling it a showstopper?
Unlike Microsoft's case, this one wasn't required for backwards compatibility. It was simply a dumb decision that nobody wanted to revisit.
If that’s not technically a “bug” then it’s still broken UX (and the error message produced certainly doesn’t help there either).
Design flaw? Hell yes.
> CP/M actually didn't do these special names as simply as I described them, which is a fact I either never learned or had since forgot.
> It actually required them to be followed by a colon, as if they were a drive name.
> So PRN: is the printer, PRN is not.
Here's a quirk that's harder to explain: open a powershell window in windows 10. Hit alt-enter rapidly to switch back-and-forth to full-screen mode while looking at the min/max/close buttons. You can see flashes of windows-vista-era buttons. Is the new look just painted on top of the old one? That's crazy!
During Windows 7's development, the responsibility of painting window frames moved from the application to a separate process known as the Desktop Window Manager, "dwm.exe". DWM tells the app that it should stop drawing its own frame when the application is windowed, and tells it is in charge of drawing "the frame" when fullscreen.
This is communicated using an asynchronous protocol (private window messages), thus during the transition it's possible for the window's idea of its frame state to be "out of sync" with the real state because the client hasn't processed all of its messages yet.
My hunch is that something similar's happening here: when you bring a Windows Console window full-screen, it disables its window decorations and the DWM stops drawing them. Through some quirk of timing, it looks like the console window itself starts attempting to draw its decorations, and, when that happens, you'll see Vista-style decorations very briefly, because that's what the theme tells it to draw.
(I suppose it's also possible that console windows always draw their title bars themselves underneath the DWM-provided decorations... they've always been a bit weird in Windows.)
Update: this link adds the tidbit that IBM was concerned about 3rd party utilities that made assumptions about the slash.
I’d want to argue that removing bugs and fixing things like this should just be done with a reasonable notice period and if some aging system in the basement of a fortune500 company blows up then I’m sure that can be solved too.
This said, I find the 70s smell more present and annoying in a Unix terminal than in Windows explorer. All the big OS’es are dinosaurs and it will show up here and there.
The fix might potentially break some apps. So at the end there could be more pissed people after the fix, than there is now unhappy about the file naming restriction.
That said, I had an error in that original post which this weirdly replicates: CP/M doesn't actually have quite this same error, because these names show up through the PIP command, IIRC. I really want to link to the correction, but I can't find someone telling me what the actual correction is from the last time that got posted.
Case insensitivity would make sense to me if all files were stored and displayed as completely lowercase (although I'm not sure how this generalizes to other character sets).
(1) My Buck BUILD file can exist alongside my build/ directory.
(2) Outside of a 0x00 or 0x2F byte, I love not having to think about locales, character encodings, normalizations, etc. especially as I am sharing files across computers which may use different values for these.
macOS went from case-insensitve to optionally case-sensitive for what I suspect are similar reasons.
Autocompletion stops early because 'SomeReallyLongSourceName.h' and 'SomereallyLongSourceName.cpp' are not the same after the fifth letter. It breaks globbing.
File explorers, etc. are user interfaces.
File system and operating system bound together, with Linux you can put lot of stuff on NTFS volume, which just gets booted when you run chkdsk on Windows machine for first time.
All Unix derivatives look at the first bytes of the file to understand what it is. See man 5 magic for details. The shebang #! is one of those magic values and it makes the OS read the next bytes up to an end of line to get the interpreter and arguments to pass the rest of the file to.
Maybe CPM used extensions to gain some speed (no need to inspect the file), not that hardware running Unix was fast by today's standards. Or maybe to force users to declare the purpose of the file in the name. However, as all unnecessary things it eventually came back to bite people.
The data type of a file is metadata and metadata shouldn't be determined by in-band signaling.
What are you going to do if your system miscategorizes a file? File name extensions are not ideal either as they overload the file name (they are out-of-band signalling regarding the content of the file but in-band regarding the file name) but at least you can change them yourself.
The file type is an inherent pair of the file content, and must move together. Otherwise your images and documents become only a meaningless set of bytes. The information that "this is a png image" is as much a responsibility of the machine that is sending you the file as the pixel data.
Also, yes, accepting random data from a network is a big security risk. It's up to your OS to handle that data in a secure way, but this is not done by removing the "this is an executable" mark.
Maybe that metadata could be stored in the file's name, like "<filename><separator><format identifier>" or something?
It's deeper than that, although this is a very good point.
Who teaches the OS what file types exist? How is that updated?
You could rely on the OS vendor, but that's a bottleneck, especially for a consumer-focused OS where most of the applications (and, therefore, most of the application file formats) are not created by the OS vendor, or entities working in concert with the OS vendor. You could have a great new file format and a great new application and be unable to use it, or get anyone else to use it, because the people behind the OS haven't caught up yet, or because the OS updates haven't percolated out yet.
You could trust the application vendors to do it, which is a security hole: The ScuzzyTech Hyper Word Processor really, really wants to open your word processing documents, so it can synergize your monetization with microtransaction-based leveraged technologies. Therefore, all of your Normalcore Text Documents are now ScuzzyTech Hyper Word Documents only to be opened by the ScuzzyTech Hyper Word Processor, because the ScuzzyTech code helpfully updated all of your filetypes and, therefore, file associations.
That said, this gives you no security benefit at all. It's basically the same thing we have now, but done correctly.
#! is special - and not because of magic(5) - if a file starts with `#!`, exec and friends will treat it special. Anything else will be attempted to be executed as a binary.
Now, one _could_ go and install binfmt_misc and set it up so that files with a jar's magic number will be executed a certain way (`java -jar ...`), but this is neither out of the box nor something that all Unix derivatives do.
Notably, binfmt_misc will also work with extensions instead of magic numbers.
Or, share your modern printer, then:
NET USE LPT1 \\server\shared_printer
Full read access on the entire volume!
archive.org link: https://web.archive.org/web/20181104213003/https:/twitter.co...
And here's my personal tweet: https://twitter.com/CrankyLinuxUser/status/10558609139858063...
I credit HN user "ageitgey" for this.
This seems just wrong and also dangerous in my eyes.
Here's some history:
Not being able to use / in filenames under Linux is slightly different because the / has an actual legitimate widespread use with no real alternative.
However similar trick probably would work in Windows as well. Does anybody care to try? :)
Using long UNC paths or writing to the FAT/NTFS filesystem through mechanisms other than Win32 allows you to bypass the restriction.
If you really want to be nasty to someone: echo hello > \\.\C:\Con.fess.I.know.what.you.did
It was not "storytelling", he was not writing it with the main goal of "getting to the point" so you could benefit. Calling it "crappy" sounds unfair and mean to me.
Yeah, its an old issue, obviously nobody cared enough to fix it until now, STFU...
edit- and finally, its twitter. stick to the character limit, or put it in a blog post.
(and maybe this should be my last beer :)
> Gary Kiddal
....I just died a little inside
I made this rant at 5am after being in the hospital for 8 hours, I could barely see the screen. It's amazing the thread doesn't have even more typos
Apparently this post is just a series of copy pasted tweet, which makes it quite difficult to understand.
Refresh a few times.
Using Chrome didn't trigger that error.