• (cs)

    Way, way back in the days of DOS, I created a batch file that attempted to delete a directory by deleting the contents of that directory and then deleting the directory itself.

    Here's version 1.0:

    cd %1 del . cd .. rmdir %1

    This handy-dandy little batch file worked great back in the days when DOS commands didn't have handy-dandy options like the ability to delete a directory and its contents at the same time.

    Of course, if you typo-ed:

    C:> deldir mydaya

    And the real directory was called "mydata", you'd be in for a little reinstalling. Hopefully, you had a backup of autoexec.bat and config.sys!

    I did learn from my mistakes, however; here's version 2.0:

    del %1*.* rmdir %1

    It's even shorter!

    (Apologies if I got any of the exact details of the DOS stuff wrong, it has been quite a while.)

  • Anonymous (unregistered)

    Ah, reminds me of a CVS mistake I once made.

    I wanted to tag all files in a directory, so I typed "cvs tag <tagname>", the problem was that I was in a different directory than I expected, so I tagged ALL files in the ENTIRE CVS tree. This coincided with a planned migration to a new system, so I tagged a lot of files that were meant for a system that wasn't in production.

    The real WTF is that I just typed in the command and didn't look at the results (were too busy with other stuff)

    The next day the web service was down for a few hours... No problem, just let the millions of users get broken web pages...

  • NiceWTF (unregistered) in reply to obediah
    obediah:
    Wow it didn't take long for to cash in all the karma gained from the awesome bomb cam post. :(

    "lul, I deleted my OS files" jokes are as old as..well..OS files.

    Only as old as Microsoft operating systems, you mean. The rest of the world has used file permissions since about 1970.

    (ok ok, we know that nobody ever makes mistakes while logged in as root/admin, right? But at least you wouldn't be logged in as such during normal development).

  • mickeyding (unregistered) in reply to a nonee mouse

    I had a similar experience some time ago when trying to clean up a disk drive of files with a ".tmp" extension on a unix box. A certain application would leave these files sprinkled behind and it was clogging the system. I was using rm -rf *.tmp at the console and inadvertently touched the spacebar just before the "." key. When I figured out the mistake it was too late as half of the bin directory had been clobbered by the time ctrl C took effect. The lessons learnt :- (1) When using a delete command always put your hands behind your back while you read the line just typed. (2) Don't do things in a hurry. I managed to get the bin directory back from a tape backup but it wasn't easy with most of the OS removed.

  • Cope with IT (unregistered) in reply to Vlad Patryshev

    Yes, and it's known as 'automatic file system cleaning operation'...

  • Cope with IT (unregistered) in reply to snoofle

    Why would you want to do that? ... If instead you could use whatever temporary file class is available to the programming language you're using?

  • Dave (unregistered) in reply to real_aardvark
    Fnord:
    Ignoring language wars, and just mentioning in passing that C++ has always been set up to do this sort of thing, it is indeed correct to say that, if you write to a temporary file, you should be responsible for deleting the bloody thing afterwards.
    plus, there's almost always a good reason not to use hardcoded paths for temp files. one should use mktemp or a similar thing.
    Fnord:
    Even idiots wouldn't do this on an interactive command-line.
    I've done it. countless times. those pesky rm -rf * entries in bash_history :) the kick you get when afterwards you realize you were in the wrong directory is quite indescribable... in fact, i've done it so many times that I've now replaced rm with a custom version that requires me to type 'yes' whenever -f, -r or a wildcard is used... it also taught me how important backups are.
  • (cs) in reply to Fnord
    Fnord:
    Do some developers have a problem with the concept of a "temporary" file? If the file is temporary, you should delete it as soon as you have finished with it. Not leave it on disk. If you leave it on disk, for whatever reason, it isn't temporary is it?
    Temporary. Compare with Transient.

    If you read the story, you'll notice that the bug was in the code to clean up the temporary files after use. That is the application did attempt to "Not leave it on disk"...

    And the real WTF is that a restricted user is allowed to wipe out the root directory. What you way? Running as Administrator? Ah, well...

  • mikko (unregistered) in reply to Grant D. Noir
    Grant D. Noir:
    Zygo:
    boyd:
    And btw the bug is not in the function deleting *.* but in the function that return c:\ as the temp directory.

    Actually the bug is that deleting . in c:\ did anything other than raise errors (restrictions on the directory are too weak or the privileges of the invoking user are too high), or remove data files owned by the user (which would have been bad, but not debilitating to the system) or the application (which were intended to be deleted anyway).

    The problem can be even worse on non-Windows systems. I've lost count of the number of times I've seen a maintainer script that looks like this:

    eval cat "$configFile" rm -rf "$dataDir"/*

    which is great if $configFile exists and contains a line that looks like 'dataDir=/foo'; however, if $configFile does not exist, or is empty, or doesn't bother to define dataDir, then the expanded command becomes

    rm -rf /*

    This too would be acceptable, provided it's executing as the owner of the software (instead of root)...which it invariably isn't...

    Thats why I'll always put an echo in front of frisky commands, before running them for real.

    This reminds me of a former cow-orker, who wrote a script to run as nightly cron-job. Of course, the last thing the script did was to take out its trash. All the trash.

    The next morning the box was .. acting up. Apparently something had wiped the system32 directory during the night.

    I just gotta know - what's an orker? And what does he do to cows? And does it pay well? (I need a new job)...

  • C Dull (unregistered)

    I'm guilty of something similar....but when I rebooted myself this morning my memory was erased and cannot remember what it was. But I'm sure I'm guilty of something....

  • Andy (unregistered)

    I have a similar one, that probably cause more damage: the installer of a software we wrote was not able to clean up upon uninstalling, so the developer made a function that would recursively delete everyting in the installation path (or so he thought .. in reality it went to the root of the fs).

    Now: a) this was installshield multi platform .. so it toasted windows and linux alike b) on linux, people had the bad (and still have) the habit of keeping our main file server shares mounter)

    As such, not only were several computer toasted, but our file sharing repositor got 70% wiped out and it took a while to figure out what was going on (a QA worked needed to devel some code and got devel rights, so had quite some rights assigned ... the rigths were revoked after this incident).

  • Daniel Albuschat (unregistered) in reply to pitchingchris

    Which also means they wouldn't have found the bug.

    CAPTCHA: tacos, but I just had pizza

  • anon (unregistered) in reply to mikko
    mikko:
    Grant D. Noir:
    Zygo:
    boyd:
    And btw the bug is not in the function deleting *.* but in the function that return c:\ as the temp directory.

    Actually the bug is that deleting . in c:\ did anything other than raise errors (restrictions on the directory are too weak or the privileges of the invoking user are too high), or remove data files owned by the user (which would have been bad, but not debilitating to the system) or the application (which were intended to be deleted anyway).

    The problem can be even worse on non-Windows systems. I've lost count of the number of times I've seen a maintainer script that looks like this:

    eval cat "$configFile" rm -rf "$dataDir"/*

    which is great if $configFile exists and contains a line that looks like 'dataDir=/foo'; however, if $configFile does not exist, or is empty, or doesn't bother to define dataDir, then the expanded command becomes

    rm -rf /*

    This too would be acceptable, provided it's executing as the owner of the software (instead of root)...which it invariably isn't...

    Thats why I'll always put an echo in front of frisky commands, before running them for real.

    This reminds me of a former cow-orker, who wrote a script to run as nightly cron-job. Of course, the last thing the script did was to take out its trash. All the trash.

    The next morning the box was .. acting up. Apparently something had wiped the system32 directory during the night.

    I just gotta know - what's an orker? And what does he do to cows? And does it pay well? (I need a new job)...

    From the context, a "cow-orker" sounds like a "Windows programmer". I hear it can pay well, but you have to deal with the loss of dignity.

  • (cs) in reply to mikko
    mikko:
    I just gotta know - what's an orker? And what does he do to cows? And does it pay well? (I need a new job)...
    You think this "Internet" thing started in 1993, don't you?

    Kids these days... (I was more interested in the "frisky commands" myself.)

  • Interface (unregistered)

    the real WTF is a developer moving into a sales role?

  • Kerry (unregistered) in reply to iMalc
    iMalc:
    That reminds me, be very careful with Uninstalling "Sierra Utilities". More specifically - don't do it! It puts this little app just outside the folder it installed to. E.g. C:\Games\ Thus upon uninstalling it removes not just C:\Games\SomeGame, but it actually deletes everything in C:\Games.

    I wasn't pleased that I then had to reinstall all of my games!

    I was just about to post this exactly. I guess I'm not the only one who installs his games into c:\games instead of the default path :)

  • (cs)

    I have a hard time considering this a WTF, simply because the problem was caught during testing. If it was found by an end user it would certainly be a huge WTF. But finding bugs, big and small, is what testing is for.

  • Chris (unregistered)

    I heard of the IT guy in my school when he got this "new" RM Nimbus "almost but not quite a PC" wanted to delete a directory from the HD. He knew the command as DELTREE, so typed it in, expecing it to report back the options that it can take and how to use it. He was in C:\ at the time, and watched the contents of the HD vanish.

    When I was at uni (late 90s) the uni had some werid restricted DOS shell on their DOS-based PCs (handy for telnet when everyone else was using all the NT boxes). One of the things you couldn't do was change drives, so if you typed A:, it just left you in C:.

    I wanted to wipe the contents of a floppy disk do I entered

    A: DEL .

    And since it ignored the A: command, it wiped the top level of their C: drive. Serves the bastards right for their retarted DOS shell.

  • Thomas (unregistered) in reply to ArchAngelQ

    Reminds me of an nokia product that decided to take out my full user account (windows C:/Documents and Settings/<deleted accont>) during uninstall.

    It left a oh-so similar empty account with my name on it, except an ø (nordic letter) converted to an o. Afterwords some nokia dude clamied it probably was something wrong with my system, since that had previously been the case with someone else's error report. I guess file systems must be very buggy things.

    Lesson?

    No nordic letters in usernames, god damnit.

  • (cs)

    I call shenanagans. "delete ." would only delete everything in the root directory. Even if there was a recursive delete command it couldn't delete anything that was being used by the operating system.

  • (cs) in reply to bradfoje
    bradfoje:
    I call shenanagans. "delete *.*" would only delete everything in the root directory. Even if there was a recursive delete command it couldn't delete anything that was being used by the operating system.

    As has already been pointed out several times, this is a DOS system, and deleting MSDOS.SYS from the root directory will destroy the OS.

  • Zygo (unregistered) in reply to Dave
    Dave:
    I've done it. countless times. those pesky rm -rf * entries in bash_history :) the kick you get when afterwards you realize you were in the wrong directory is quite indescribable... in fact, i've done it so many times that I've now replaced rm with a custom version that requires me to type 'yes' whenever -f, -r or a wildcard is used... it also taught me how important backups are.

    I live with cats.

    Cats like to climb onto keyboards.

    Keyboards are designed with a layout that makes pressing up-arrow and Enter easy to do while walking across the keyboard begging for attention, or curling up to sleep. (actually up and left-arrow are equally likely, but left-arrow is irrelevant).

    Things I've learned from my cats:

    1. Whenever I delete anything with wildcards, I use the full path to the thing being deleted ($PWD<TAB> in bash does this quite efficiently). That way, the cats only delete some specific object I've deleted before, not <some random wildcard> vs. <some random directory>.

    2. I don't usually delete things directly--I have a command-line utility that moves files to a "trash" directory on the same disk, then another utility that removes them as the disk gets full. This gives me a chance to change my mind, or restore data after the cats have visited.

    3. All my terminals lock automatically after the minimum tolerable time interval (between 2 and 5 minutes depending on the level of feline access to the location). No exceptions. This forces the cats to type a password, and so far they haven't guessed what it is.

    4. Never use 'vi' if there are cats in the room that are not otherwise occupied with sleeping or eating tasks. Typing random keystrokes into vi does really bizarre and subtle things, like inserting spaces into wildcard expressions, or inserting wildcard expressions at random places in the code.

  • Zygo (unregistered) in reply to mikko
    mikko:
    I just gotta know - what's an orker? And what does he do to cows? And does it pay well? (I need a new job)...

    If there isn't a Wikipedia article on it, go to dilbert.com and read the DNRC newsletter.

  • (cs) in reply to C Dull
    C Dull:
    I'm guilty of something similar....but when I rebooted myself this morning my memory was erased and cannot remember what it was. But I'm sure I'm guilty of something....
    So when did the Bush administration start reading this site?
  • AdT (unregistered) in reply to Nanoda
    Nanoda:
    I didn't remember writing it, but subversion said it was my fault, so karma levels were appropriate.

    The company where I work switched from using VSS to Subversion some year ago. I said that the ability to quickly find out who checked in a given line of code using the Blame function was one of the primary advantages of Subversion over SourceSafe.

    My co-workers insisted it was one of the primary disadvantages.

  • (cs) in reply to Zygo
    Zygo:
    I live with cats.

    Cats like to climb onto keyboards.

    Keyboards are designed with a layout that makes pressing up-arrow and Enter easy to do while walking across the keyboard begging for attention, or curling up to sleep. (actually up and left-arrow are equally likely, but left-arrow is irrelevant).

    Things I've learned from my cats:

    <snip/>
    1. Never use 'vi' if there are cats in the room that are not otherwise occupied with sleeping or eating tasks. Typing random keystrokes into vi does really bizarre and subtle things, like inserting spaces into wildcard expressions, or inserting wildcard expressions at random places in the code.
    HAH! The ultimate answer to Editor Flame Wars! Emacs is obviously better, because it isn't modal and therefore has a more reliable "undo" (or "un-cat") mechanism. Mind you, elisp does have a tendency to look like it was written by my cat. And it's often to be found in the scratch buffer ...

    And to anybody who says, "Keep vi and get rid of the cats," well ...

    ... You're just a sick puppy aren't you?

  • Hasse Wehner (unregistered)

    Brilliant! :-)

    Hasse Wehner -- http://hassewehner.blogspot.com/

  • Andy Goth (unregistered) in reply to Dave
    Dave:
    in fact, i've done it so many times that I've now replaced rm with a custom version that requires me to type 'yes' whenever -f, -r or a wildcard is used.

    How can rm (or a replacement) know if a wildcard was used?

  • (cs) in reply to Hasse Wehner
    Hasse Wehner:
    Brilliant! :-)

    I think the word you're searching for is "brillant".

    Let's see how many ignorant people try to correct my spelling this time!

  • derf (unregistered) in reply to Belcat

    I once worked for a company that made anti-virus products in the capacity of software tester. Once, while trying to hit yet another unrealistic deadline, development sent us a build to beat on. Well, it turns out, that initiating any scan would leave you with a giant blob of useless data. In other words, it used a ffind type of method that just concatenated every file into one very, very large, nameless blob. I wrote that bug up, and made sure to write "WARNING DO NOT TRY TO REPRODUCE OUTSIDE OF QA". That one statement went a long, long way with the developer assigned to fix the bug. He just had to run down to my machine and look... and he laughed his ass off all the way back to his pristine box... I rebuilt mine. That's why to this day, I insist on having TWO machines for each tester. (I had two then, too)

  • (cs)

    I might have just had a Baader-Meinhof experience... I read this article a few hours ago, and just came across this bit o' nuttiness while trying to decipher some ancient code:

    AfxMessageBox("I dont think that you want to delete C: directory.\n
Next time choose something else!\n
Remember that all the files of the chossen directory will be deleted!");
  • knock it off... (unregistered) in reply to Someone You Know
    Someone You Know:
    Hasse Wehner:
    Brilliant! :-)

    I think the word you're searching for is "brillant".

    Let's see how many ignorant people try to correct my spelling this time!

    aha, it's you again.

    those people are not "ignorant", they're just not reading this page as long as you do. it does not speak of anyone's intelligence to blame or ridicule others for such a thing.

    oh wait... perhaps it's because these other people do have a life and therefore can't read all (past) articles?

    it might have been funny, if you'd mentioned "brillant" and included the link to the original story, at least after someone has been trying to correct you, instead of ridiculing him/her.

    but nothing better than a cheap thrill, eh?

    BTW, your name is fitting indeed, I do unfortunately know others who are a lot like you.

    as it is, your know-it-all attitude is just a pain in the a...-ahem- neck. if someone knew all the stuff where you are a rookie and/or an ignoramus, I bet he'd most probably be on the brink of omniscience...

    BTW, the captcha is also a pain in the respective body part: starts with r, continues with i and ends with aa... ;-)

  • James (unregistered)

    Absolutely true story:

    When I was a kid, I had an Apple ][ -- that was my "native tongue". I had tinkered with "IBM Clones" just often enough to be dangerous. I was babysitting for some neighbors (good friends of the family, actually), and I installed a game a friend had given me on their computer -- I think it was some version of TMNT, running on a 486. When I was going to leave at the end of the night, I wanted to delete it (hard drives were, of course, tiny in those days -- ~100 MB was pretty big, IIRC). What did I do?

    CD\
CD TMNT
DEL *.*
(yes)
DIR

    Hmm, there's still "." and ".." -- those must be special files.

    DEL .
(yes)
DEL ..
(yes)

    For those not familiar with the vagaries of DOS, that last "yes" deleted all files in C:\ (not, thank God, recursively). Running "DEL .." on a directory one above root on my current (XP) system prompts to "Delete C:*.*?", but I'm not sure what it did in DOS 6.x.

    Of course, I found out what happened moments later when I saw some wierd behavior or other in the system, and tried to reboot. Total boot failure (no CONFIG.SYS, AUTOEXEC.BAT, etc). I had no idea how to troubleshoot it, and I think I was young enough it didn't occur to me to bluff my way out by feigning ignorance. I panicked, got yelled at, and never babysat for that family again -- in fact, I felt awkward around them for years.

    I think they fixed it eventually -- undelete worked wonders if you knew what you were doing, honestly -- but I never found out for sure.

  • anonymity desired (unregistered) in reply to real_aardvark
    real_aardvark:
    Ah yes, the old "Resource Acquisition is Initialisation" pattern. Which doesn't actually feature in any "Pattern" book of which I am aware. And in fact is a pretty piss-poor acronym, because we should all replace "Initialisation" with "Ownership." It's worth a baker's dozen of the other ones, though, and it's surprisingly rare in practice.
    It's a C++-specific pattern, though the principle should hold true in other languages too. Indeed, there they can use custom blocks so that the syntax is a little more natural. (Or at least there is one example that definitely does this sort of thing, making things like database transactions a real doddle, especially as they can decide on the manner of resource releasing depending on whether there's an exception blowing through or not.)

    Some languages don't make this sort of thing all that easy though. (For example, Java uses finally clauses, but that doesn't make it so easy to do things like rollback-on-exception...) Some (C, I'm looking at you!) don't do anything at all to help.

    If you write to a temporary file, you should be responsible for deleting the bloody thing afterwards.
    Agreed!
    However, the number of times I've seen Shell scripts, Perl scripts, and probably even Python and Ruby scripts, try to change directory relative to the root (Windows or Unix, who cares?), fail (thus leaving the poor little script at the root), and then "clean up" via rm . is truly humbling.
    Something I've learned from many years of experience: never ever change directory in a program (compiled or script) that takes a filename as an argument (or via an environment variable). The confusion that ensues from "changing where the world starts" isn't worth any amount of convenience on your part. Best of all is to instead convert each filename that you're going to work with to absolute form at the start of the program run and then stash them all in variables. You might think you can take shortcuts, but unless you want your barber calling you Baldy, don't do it!

    Oh, and remember that Good Programs Don't Delete With Wildcards.

  • Fnord (unregistered) in reply to AdT
    I said that the ability to quickly find out who checked in a given line of code using the Blame function was one of the primary advantages of Subversion over SourceSafe.

    I would have said that the fact is wasn't SourceSafe to be a primary advantage. The ability to work without your source repositories becoming irreparably damaged would also be a plus.

  • Nk (unregistered)

    Reminds me of my first programming project ever.

    After much work, I finally had something working. Now all I needed was an installer and an uninstaller. Back in 1996, the only name you'd hear in the installer area was InstallShield (or at least that's the only one I knew by then), and it cost money. So I decided to try making some fancy .bat files.

    The uninstaller would first confirm if you were sure you'd want the software to uninstall. That was done using MS-DOS' "choice" command, then the checking the errorlevel. Right after finishing writing the uninstaller, I ran it to test the confirmation.

    And I got the errorlevel test backwards.

  • GrandMasterBirt (unregistered) in reply to shadowman

    Yea user account controll to the rescue... We always recommend our software be installed on a linux/unix system under a separate account with minimal privilages necessary to run the code. That way even if we decide to f*** up every way possible, we dont delete root!

  • Stefan W. (unregistered) in reply to Zygo
    Zygo:
    I live with cats.

    Cats like to climb onto keyboards.

    Living with cats is a good habit.

    However - interesting to see, that cat's are far more interested in keyboards than mice.

    Perhaps hacking on rfid could improve your security: if cat is far away: normal mode if cat is close: switch to restricted mode, which is divided by your own rfid: if you're close: restricted "cat is watched"-mode else: very very restricted mode.

    Always keep your online-banking password secret, or you'll find your cats gambling on the beef-exchange, or ordering albacore containers. :)

  • anonymity desired (unregistered) in reply to Andy Goth
    Andy Goth:
    How can rm (or a replacement) know if a wildcard was used?
    On Windows, it's fairly easy if you hook at the right place because wildcard expansion is done by the called program and not the calling shell (though your libc may well hide this fact from you). On Unix, your only chance is to look at the order of arguments and guess whether they match what a glob would produce (in other words, it's ridiculously difficult and you shouldn't bother.) I've seen some people instead alias 'rm' to 'rm -i' so that when they delete things they get a double-check unless they turn it off by hand. I prefer to not delete things at all (except using undoable GUI mechanisms) myself, except for program-generated files and my code never deletes those with a wildcard. (I've not lost data in a manner like this WTF for around 15 years now and I'm still paranoid...)
  • Corporate Cog (unregistered) in reply to Someone You Know
    Someone You Know:
    Corporate Cog:
    If that key is deleted, the machine will work almost normally (only one strange thing was reported) until rebooted. There is no way to reboot. The file system must be accessed by booting to some other drive.

    I'm curious to know what the one strange thing was.

    IIRC it was a problem with trying to install fonts.

  • Joe (unregistered) in reply to Fnord

    Why does noone use FILE_FLAG_DELETE_ON_CLOSE anymore?

  • Andy Goth (unregistered) in reply to anonymity desired
    anonymity desired:
    On Unix, your only chance [to check for wildcard] is to look at the order of arguments and guess whether they match what a glob would produce (in other words, it's ridiculously difficult and you shouldn't bother.) I've seen some people instead alias 'rm' to 'rm -i' so that when they delete things they get a double-check unless they turn it off by hand.

    I am an "rm -i" user. It has saved me many times. I also alias -i onto cp, mv, and ln.

    With some rm implementations I can type "rm -f" and the -f will override the -i passed earlier by the alias. But with others I have to type "\rm" to temporarily disable the alias. (Useful tip!!)

    Stupid idea: Modify the shell to add some level of support for scripted wildcard expansion in the context of certain commands (list supplied by the user, of course). For rm, the wildcard scripts, if invoked, print warnings and ask for confirmation. 'Cuz you know, the shell isn't bloated enough, and we need to keep adding features until it's a respectable size.

    Stupid idea #2: Make wildcard expansion much harder. * is too easy to type, damn it!

    Reasonable idea: Take your advice and avoid interactive use of rm.

    However, none of these (or their DOS/Windows analogues) would have prevented the WTF from biting. Solution? Permissions.

    But permissions won't help in the case of the uninstaller WTFs mentioned above, as a user who has permission to uninstall one program almost always has permission to uninstall other programs in sibling directories.

  • AdT (unregistered) in reply to Fnord
    Fnord:
    I would have said that the fact is wasn't SourceSafe to be a primary advantage. The ability to work without your source repositories becoming irreparably damaged would also be a plus.

    Surprisingly, while we encountered a few errors like "File AAAAAAAB could not be found", we never lost data when using SourceSafe. At least none that we ever missed. Of course that may have been pure luck, but using VSS was never my decision anyway. Subversion is so much better. Even CVS is better.

    Everyone has a different idea of what's the best feature of Subversion over VSS though. For our mobile workers, probably the greatest advantage is that using Subversion over UMTS offers acceptable speed whereas using VSS over UMTS was like cutting down a redwood tree with a nail file.

  • (cs) in reply to Uber
    Uber:
    The real WTF is that we still use C: Where are A: and B:
    It's historical. We've always used C: for the main hard-disk, and if it was changed a lot of hard-coded programs would break.

    There's a similar problem if D: is a hard-disk and not an optical drive with some older games. The number of times I've installed a game from E: (2nd optical drive) and it then insists on the disk being in D: (1st optical drive) to run (even if launching from the disk in E:'s autorun), or I install to F: (2nd hard disk), and it places a desktop shortcut to C:... Thankfully these stupid errors seem to have disappeared in recent years.

    Windows will happily let you mount drives or shares to A: and B:, there's nothing stopping you.

  • Dick McBeef (unregistered) in reply to Renan_S2
    Renan_S2:
    I think that, if you deleted NTLDR from the C:\ of a Windows NT/2K/XP/(Vista?) system, it would refuse to boot with an "NTLDR missing" error.

    Which reminds me of an error message I encountered recently -- quite possibly the stupidest and most totally useless error message ever:

    NTLDR missing Press Ctrl Alt Del to re-start

    Just think about it for a moment and ponder the true stupidity of this message. If my computer can't boot because NTLDR is missing, what will be accomplished by pressing Ctrl Alt Del to re-start?

    captcha: onomatopoeia

    Now *THAT'S a WTF!!!

  • (cs) in reply to knock it off...
    knock it off...:
    Someone You Know:
    Hasse Wehner:
    Brilliant! :-)

    I think the word you're searching for is "brillant".

    Let's see how many ignorant people try to correct my spelling this time!

    aha, it's you again.

    those people are not "ignorant", they're just not reading this page as long as you do. it does not speak of anyone's intelligence to blame or ridicule others for such a thing.

    oh wait... perhaps it's because these other people do have a life and therefore can't read all (past) articles?

    it might have been funny, if you'd mentioned "brillant" and included the link to the original story, at least after someone has been trying to correct you, instead of ridiculing him/her.

    but nothing better than a cheap thrill, eh?

    BTW, your name is fitting indeed, I do unfortunately know others who are a lot like you.

    as it is, your know-it-all attitude is just a pain in the a...-ahem- neck. if someone knew all the stuff where you are a rookie and/or an ignoramus, I bet he'd most probably be on the brink of omniscience...

    BTW, the captcha is also a pain in the respective body part: starts with r, continues with i and ends with aa... ;-)

    I did not make any reference to anyone's intelligence. I did not ridicule anyone. I was merely making light of the fact that so many people were so quick to correct a perceived error the last time I made a similar remark.

    And yes, people who don't know something are ignorant of it. That's what the word "ignorant" means: uninformed or lacking knowledge. The fact that many people use it, incorrectly, in an insulting way is not my problem. It is not insulting to simply not know something. I wasn't making fun of anyone for not knowing the "brillant" reference. I'm sorry if you did not understand or appreciate my humor, but that is not my problem either.

  • Andrew (unregistered)

    There is a WTF with the IT support person too. Just boot off a floppy or CD. Then reinstall the OS. del . in c:\ only deletes the files in that dir. The disk just needs to be made bootable again. In MS-DOS its as simple as "sys c:" after booting from the floppy.

  • (cs) in reply to Joe
    Joe:
    Why does noone use FILE_FLAG_DELETE_ON_CLOSE anymore?
    Because not all systems are Win32 systems, and not every temporary file is local to the application that wrote it.

    For example, if you have two applications working together where one app passes data to another, having the first application specify that flag may cause the file to vanish before the second app can get to the data.

    Yes, you can open/create the file allowing sharing, but then you have to sync up the two apps so you know when it has got a handle on the file, etc.

    This is another reason why RAII is not a catch-all for problems like this...

    -=- James.

  • Cloak (unregistered) in reply to Someone You Know
    Someone You Know:
    Hasse Wehner:
    Brilliant! :-)

    I think the word you're searching for is "brillant".

    Let's see how many ignorant people try to correct my spelling this time!

    Given the poster's name he must be a German speaker and, hence, "Brilliant" is the correct German spelling. Now what?

  • regeya (unregistered) in reply to knock it off...

    "those people are not "ignorant", they're just not reading this page as long as you do. it does not speak of anyone's intelligence to blame or ridicule others for such a thing."

    I believe in helping the ignorant:

    http://wsu.edu/~brians/errors/ignorant.html

    you're welcome.

Leave a comment on “Good Thing we Tested It”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article