According to these threads on the EVE Online boards, a flaw in an optional EVE:Trinity patch sometimes erases the boot.ini in the Windows directory instead of in the EVE Online directory. Unfortunately, c:\boot.ini is one of the main files used during the boot process of windows, and without a proper boot.ini file, Windows simply won’t start. The file is only used in the boot process, so it will run fine until it’s rebooted, at which point, getting the machine up and running again requires some fun tech support-type work.
Putting aside the obvious question, “How did this get past QA,” why would you ever name a file the same thing as an essential part of the OS? That’s just begging for trouble.
CCP delivers. *thumbs up*
I had my boot.ini file corrupted once…This lead to me calling tech support after Microsoft’s fix didn’t seem to be working, just to get told that I needed to buy a new HDD (then quickly forwarded to their sales department). Turns out there was just some small issues with my monitor and keyboard (monitor didn’t show startup screen for some reason, so I had to hold F12 while cutting my PC on, and the menu after pressing F12 wouldn’t work because of my stupid keyboard drivers) and I ended up fixing it…nothing wrong with my HDD.
But oh well, that’s irrelevant, just reminded me of that one time a stupid tech support guy tried to sell me an HDD instead of helping me fix a problem. Oh yeah, and did I mention it seemed like he was reading the same exact Microsoft fix I was reading before I called him?
Using .ini files in programming isn’t that unusual. TES: Oblivion does it, as do a good many specialized files. In Windows environments, it’s considered a best practice for plain-text files used for starting up a program in some circles.
Naming it boot was a poor decision, but in all honesty, not really the issue here. Any program which writes outside of its folder can be incredibly destructive; taking out your term paper or home-coded project is just as much of a problem as taking out boot.ini.
What was stupid was using relative paths, not having the software check ownership/creation/directory, and then not doing near enough alpha and beta testing.
Thankfully, it’s an easy fix. A Windows Install Disk can do a non-destructive repair install or simply repair the boot sector from command line, and many Linux liveCDs have the ability to fix this sorta problem with a text editor.
I don’t envy their tech support line, though.
Big mistake by CCP, no doubt – but why does Windows allow some program to overwrite a critical system file? That kinda strikes me as the bigger ‘WTF?’ here. Oh well, I’m glad I got a Mac ;)
my PC survived at least.
xwn: If you can blow your foot off with windows, you can level a smal city block with unix :)
nine: not to start an OS war, but you’d be hard pressed to find a reasonably sane Unix-like system that would allow some random application (like a game) to overwrite critical system files. Official Apple software updates don’t count, of course. :)
Lachek, any pure Linux/Unix environment will allow you to do non-trivial damage to your own system if you’ve got enough write access to do anything useful. rm -r -f *.* would be the most cliched one, but simply editting the right xwindows file will likewise bugger you. Throwing “:(){:|:&};:” into a Bourne shell will likewise cause some non-trivial issues.
I dunno about Mac OS X’s implementation of Darwin, but I assume there’s nothing more than a sudo required tomake the above problematic.
Windows allows you to alter the boot.ini file because it’s used to name and label multiple boot partition systems. It is labeled as a system file, but there’s really not much more that can be done than that short of making it a non-editable file with Administrator-only ownership, and that gets in the way of using it to load Linux on one partition and XP on another.
gattsuru: Like I said, any “reasonably sane” Unix-like system (including most, if not all, Linux implementations) will not allow some random application (like a game) to escalate privileges such that it can overwrite or delete system files. Yes, it’s all based on the privileges of the currently logged in user, and if you run as ‘root’ you have only yourself to blame. The examples you give can destroy your own documents and application settings – like accidentally deleting all your stuff in “My Documents” on Windows – but will do nothing to the ability for the system to boot or run services defined as critical.
I excluded official Apple software updates, because they do require the ability to replace critical system files. An amusing anecdote (to those that were not affected by it) – a number of years ago, Apple released a “Critical Update” to their iTunes music player software, which included the line ‘rm -rf /’, presumably instead of ‘rm -rf .’ For the bash-script challenged, that is ‘recursively, without asking questions, remove everything at the root of the drive’ instead of ‘recursively, without asking questions, remove everything in the current directory (iTunes)’. The end result was not an updated iTunes, but a completely blank hard drive.
And yes, if you ran with limited privileges (as a ‘user’) under Windows, you’d probably not be able to accidentally overwrite your boot.ini file. Having said that, you also wouldn’t be able to do much of anything else.
We now return you to your regularly scheduled programming.