Shootout: 'rm -Rf /' vs. 'Format C:'

skyshock21 writes "There's an article over at hohle.net about what actually happens when you type the commands Format C: in windows versus rm -Rf / in Linux. Very interesting results indeed. Myths are busted, and hilarity ensues."

Comments

...vs Magnet vs Tossage

[molywi]

I prefer the magnet or throwing the disk out the window.

Re:...vs Magnet vs Tossage

[1nhuman]

Actually a Dutch (national) prosecutor did something similiar a month ago. He thought his HDD failed and put his whole PC with his garbage on the street.

Unfortunatly a Taxi driver took the PC with him and managed to boot the machine and found an enormous ammount of very confidentinial information on the HDD. Information about some top crime and fraude cases. The Taxi driver then sold this HDD to a dutch TV crime fighter.

In the end this got the prosecutor fired. Which I think is sort of unreasonable, since the major issue is the justice departments lack of descent security procedure.

Re:...vs Magnet vs Tossage

[Firethorn]

physical destruction is the only authorized destruction method for many classified drives.

On my base, we sometimes took the drives over to EOD (Explosive Ordinance Disposal). They reportably had a great time.

Re:...vs Magnet vs Tossage

[bbc]

Making fun of spelling (especially of that of a non-native speaker) is so last week.

Re:...vs Magnet vs Tossage

[Bertie]

Why? This guy's in a responsible position, he should be more careful. The buck stops with him.

Re:...vs Magnet vs Tossage

[LaCosaNostradamus]

Let me see if I understand this ... a Dutch prosecutor put his entire computer out in the trash for anyone to come by and take? Firing's too good for him. Anyone in his position should know security procedures for document handling. Are you sure he didn't break Dutch law?

Re:...vs Magnet vs Tossage

[umpa]

Unfortunatly a Taxi driver took the PC with him and managed to boot the machine and found an enormous ammount of very confidentinial information on the HDD.

When you throw something in the garbage, it's still yours. It's not free for the taking.

The taxi driver stole the computer and the "Dutch TV Crime Fighter" bought stolen property. That's criminal.

Re:...vs Magnet vs Tossage

[Le Marteau]

When you throw something in the garbage, it's still yours. It's not free for the taking.

Not in the USA. Trash is considered 'abandonded property' and is up for grabs.

Re:...vs Magnet vs Tossage

[ajs318]

I've always thought that it should be the recipient of a used storage device, howsoever acquired, who should be bound to secrecy in respect of its contents. If their intentions are honest, and all they want to do is store stuff on it, fine. If they want a little peek, well, that's pushing it. But the minute they base a decision on something they discovered there, or communicate it to a third party, they've definitely crossed a line.

Also, if you don't do a bad block scan {which wipes out any pre-existing data good and proper} on a used hard drive when you create the file system{s} on it, you're just asking for trouble.

I recommend dd if=/dev/audio of=/dev/hda1 {or whatever; but basically you want to get the raw data coming in from the sound card and write it straight to the disk partition} before passing on a used drive. Crank up the input gains to the max, but don't actually plug anything in ..... let the static and power hum do their job, which is to create entropy. After one overwrite cycle, there is no way the drive can recover the data by itself; specialised techniques are required whose cost is prohibitive and whose reliability is questionable. After two overwrite cycles {with high-enough entropy data}, even they don't work. Anything more than two overwrites is a waste of effort, and resources; there is always an easier way to reconstruct data when just one copy of it has been overwritten magnetically.

Re:...vs Magnet vs Tossage

[sumdumass]

Actually the buck should be passed on to a higher position. It is obvious that the guy wasn't computer savy and didn't have the slightest clue. After all he suspected that the harddrive was bad and threw the entire computer out.

The real problem here is that A) there wasn't some sort of tech support in place that would have made that decision instead of him. B)There isn't some sort of policy detailing what can be done with the computers or information/storage devices if somethign like this ever did happen. c) If this computer was his own, he was able to take sensitive data away from the office and place it in an unsecure enviroment. Most users don't know that if you delete somethign it is still there. The fact that there isn't a policy for situations like this or that the policy wasn't known by the employies is verry troubling.

On the other hand, this could have been nothing more then a setup to feed information to the tv reporter and the story about setting the computer to the curb because the hardrive was bad could be a failed attemp to cover it up. It would be interesting to find if the guy recieved any types of payments form the television station or any other affiliation associated with that guy.

Re:...vs Magnet vs Tossage

[hazem]

You were lucky. I worked in a Top Secret facility and we were required to disassemble the drives, and remove each platter. Then using a belt sander, we had to scrub them down to bare metal. These metal pieces were then taken to an incinerator that would mostly melt what was left.

The cool part was being able to recycle the magnesium casings on those giant-sized drives (about a foot wide, 8 inches tall, and about 2 feet long). I made a few hundred dollars on that!

I don't know what the big deal was, though. Our facility only handled... oh wait, someone's at the door...

Re:...vs Magnet vs Tossage

[cayenne8]

" Not in the USA. Trash is considered 'abandonded property' and is up for grabs.

Very true...I live in New Orleans. I think I mentioned it before, but, you put anything out that even LOOKS relatively useful (and some amazing non-useful)...and it will not be there by morning. Hehehe...one afternoon, while getting ready to move..decided it was time to get rid of some of the old playboys and such rather than move them. I put them all in a box, but, left the lid open. This was a good 40-50lbs easily...well, just went back inside packing readying for the move. Came out with another load of trash to put at the curb...the whole box was gone...hahaha. Was amazed at how fast it went and during the daytime.

Re:...vs Magnet vs Tossage

[evilviper]

we were required to disassemble the drives, and remove each platter. Then using a belt sander, we had to scrub them down to bare metal.

Platters aren't metal.

Re:...vs Magnet vs Tossage

[owlstead]

Actually he got another job at the justice dept to make use of his expert knowledge. I'm afraid that my hope that he now is cleaning up the toilets is in vain. The problem is indeed as mentioned; he should never EVER had this information on his home PC in the first place. He mentioned that a virus destroyed his PC. How the hell did he catch a virus on his home PC? Simple. It was directly connected to the internet. They cleaned out his mail account three days afterwards. Tar pit is too good for dinosaurs like him.

Re:...vs Magnet vs Tossage

[hazem]

These were, or they appeared to be.

In any case, the magnetic material was a certain color - kind of a golden brown, and the substance below was something else. We had to sand off any of the golden brown stuff so that only the underlying substance remained.

I think most platters today are made out of glass, but many years ago, they were made out of something that was very metal-like. This is back when the platters were more than a foot across. Physically, they were very large drives.

Re:...vs Magnet vs Tossage

[mvdw]

Or, better:

for i in $(seq 4) ; do
dd if=/dev/urandom of=/dev/hda
dd if=/dev/zero of=/dev/hda
done

Writes over the disk with random data, then zeroes, a total of four times. Good luck recovering anything off that puppy (although, it most likely can still be done with some *very* sophisticated equipment).

Re:...vs Magnet vs Tossage

[the narf]

They shattered because modern disk platters are made of glass. Why? Because a glass surface can be made to higher tolerances than aluminum (the material of choice in older drives) or other non-ferrous metals that have been used for platter substrates. Glass is also more dimensionally stable in changing temperatures than aluminum as well.

The older drives used 14" platters. I can still remember the Digital RP06 drives, which were OEMed from Memorex. The drives looked like black washing machines. (Wiggled around like they were on "spin dry" too when lots of seeking was going on.)

The point here, though, is that trying to cut a modern disk platter is likely to result in shards of glass all over the place...

openbsd rm

[Anonymous Coward]

openbsd has rm -P which will overwrite the bytes of the 3 times

Re:openbsd rm

[Ice_Balrog]

Linux and other *NIXes also have shred, which can do that and a bunch of other things.

For instance, 'shred -u -z file' will overwrite that file 25 times with random bits, overwrite it with all zeros to hide the shreading, then remove the file.

'info shred' (or 'man shred' for less detail) for more info on how to use shred.

Re:openbsd rm

[ajs]

#!/bin/sh
# file wiper
#
# I recommend against ever using this. It is often
# the case that you DON'T want to make sure that
# no effort used to recover a file can work.

for file in $* ; do
size=$(stat -c '%s' $file)
for i in 1 2 3 ; do
head -c $size /dev/urandom > $file
done
rm $file
done

Re:openbsd rm

[dukerobillard]

I'd never heard of shred, so I checked it out, and found this interesting tidbit in the man page:

CAUTION: Note that shred relies on a very important assumption: that the filesystem overwrites data in place. This is the traditional way to do things, but many modern filesystem designs do not satisfy this assumption. The following are examples of filesystems on which shred is not effective:

* log-structured or journaled filesystems, such as those supplied with AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.)

* filesystems that write redundant data and carry on even if some writes fail, such as RAID-based filesystems

* filesystems that make snapshots, such as Network Appliance's NFS server

* filesystems that cache in temporary locations, such as NFS version 3 clients

* compressed filesystems

Re:openbsd rm

[qray]

overwrite it with all zeros to hide the shreading, then remove the file Wouldn't it be better to replace it with the original bits. That would remove all traces of shredding. Something pithy goes here

Re:openbsd rm

[tuffy]

I'd never heard of shred, so I checked it out, and found this interesting tidbit in the man page:

CAUTION: Note that shred relies on a very important assumption: that the filesystem overwrites data in place. This is the traditional way to do things, but many modern filesystem designs do not satisfy this assumption.

This is quite true, which is why shred is generally more effective when used on an entire device (/dev/hdb, /dev/fd0, etc.) rather than on a single file on a filesystem. Even then, however, it may not be completely effective if the drive's firmware has moved your data around behind-the-scenes. But it's probably good enough for a lot of people depending on just how valuable the deleted data is.

Re:openbsd rm

[mcmonkey]

Bruce Schneier mentioned that magnetic media can be read using magnetic dust and a microscope...irrespective of the number of overwrites

I'm very skeptical of this claim. He's essentially claiming any magnetic media has an infinite capacity.

For example, take a disk with a capacity of 100 GB. I fill that with data; I read the data.

Then I overwrite the entire disk with another 100 GB of data. Of course I can read the new data. And supposedly with enough time and patience I can read the data that has been overwritten. By overwriting I've doubled the capacity of the media.

When I overwrite the disk again I can read the new data, I can recover the data I've just overwritten, and because this process is irrespective of the number of overwrites, I can retrieve the original data that has been overwritten twice.

This seems to defy some basic laws of physics, but I admit I do not know all the inner workings of magnetic media.

Re:openbsd rm

[greed]

I'm not intending to support the claim that the number of overwrites is infinite, or even large.

But I believe the basis of the claim is that, for any given "bit position" on the disc, the current magnetic reluctance of that position depends on its current state and some function of the previous state. And the previous state depends on itself and ITS previous state, and so on.

Also, the aligment of each recording cell does not precisely line up each time. There's very sophisticated circuitry in a modern drive to figure out what the bit was supposed to be. (Keep in mind that what is actually written to the disk is coded, so that you never get long runs of 0s or 1s.) All those probabilities are fed in to the decode logic to come up with actual, usable bytes.

So if you get to the magnetic surface and can assess the relative strengths of fragments of bits at each bit position, you can start to rebuild the history of that position. Then you have to re-run the decode to work out what the datablock contained.

Though I can only see this being feasible for a small number of overwrites... but I really must read some of Schneier's works.

There's a reason why we make backups; data recovery in that manner costs a fortune.

Re:openbsd rm

[zarthrag]

What he is implying, I think, is that the data isn't *completely* overridden. With specialized equipment (as that is likely an electron microscope) it is possible to uncover the overwritten data. That data will by no means be complete enough to pass a CRC check - but with time & effort, it's remotely possible to find something interestingly old.

Re:openbsd rm

[Smallpond]

Close. That was dead stars, this is deskstars.

Re:openbsd rm

[ajs]

what is "copy(\*R, \*F) or last;" from the File::Copy module giving you that you can't get from "seek F, 0;print F read S, $size"

Well, other than the fact that it doesn't work, it's fine ;-)

This is exactly why I wrote File::Copy and why it was picked up in the core: people always get the subtleties of File::Copy wrong because there are so many.

First off, the return value of "read" is a nunber, not the buffer that was read.

Second, you're not accounting for partial reads and/or writes (and, yes they happen all the time).

Third, there's no error checking in what you wrote.

Now, as for your example in shell... it's fine except for doing things in blocks. I'd drop down to bytes to avoid rounding errors (bytes left unreplaced at the end of the file).

Re:openbsd rm

[alangmead]

I'll accept your criticism about screwing up the return value of read, but I disagree about partial reads. Perl's read is equivalent to C's fread() which will retry from partial reads.

Although the shell version is working in blocks, it will not leave bytes unreplaced at the end. It might perhaps increase the logical size of the file before removes it. (du will report the number of blocks in use, and round a partial block to the next block. The file system will always allocate space in some multiple of a block size, so extending it to the end of the block won't actually increase the disk space allocated to the file.)

And since I'm enumerating what I agree and disagree with, I guess I should add that I agree with the utility of File::Copy. Thank you for it.

An interesting topic, at last!!

[faragon]

Well, without the verbose/interactive flag, it's quite more dangerous the 'rm' approach, still the word 'format' itself it is, subjectively, less musical than 'remove'.

Re:An interesting topic, at last!!

[Rosyna]

Whatever the issue is it does prove one thing... Windows' System File Restore doesn't actually work too well. I mean you can easily delete NTLDR.dll and XP won't replace it. And this test shows that windows won't replace dlls if you start deleting things en masse. I know it sounds like common knowledge but some people honestly believe that system restore on Windows is the greatest thing ever and cannot be defeated. Go figure.

A more appropriate shootout

[cyborch]

would be 'mkfs /dev/hda1' vs 'format c:'

Re:A more appropriate shootout

[Mjlner]

If you would've bothered to RTFM:
"I know that "format c:" and "rm -Rf /" aren't equivalent, but they usually are interchangeable punchlines to jokes, which is why they were chosen."

This comparison is mostly to check how well you can get a n00b to screw up his system, which is notoriously done with format and rm.

Re:A more appropriate shootout

[geoffspear]

If you want someone to screw up his system, then "while (1)
mkdir foo; cd foo
end"
is even more effective.

Re:A more appropriate shootout

[freqres]

Or try debug < losepart.src
where losepart.src is:
F 200 L1000 0
A 100
MOV AX,301
MOV BX,200
MOV CX,1
MOV DX,80
INT 13
INT 20

G
q

Re:A more appropriate shootout

[lakeland]

Right, I just tried it on ext3 and reiserfs. Neither even blinked.

However, the person who posted :(){ :|:&};:
was onto something. That killed the machine I typed it at :)

Slashdotted, mirror:

[Anonymous Coward]

http://www.dealsites.net/wrap.php?file=hohle_post. htm

Before they got slashdotted..

[pigeon]

they apparently did a rm -rf / on their webserver..

you know

[iamnotacrook]

i read that whole article, and i couldnt find the hilarity.

i'll go back to laughing at the election results. or was it crying, i cant remember now.

sudo password

[emmavl]

In the article he mentions sudo asks the root password, while it's actually asking the password of the user performing the sudo ! So I guess he must have set the root password identical to his user password during the installation.

Re:sudo password

[_Hellfire_]

I run Ubuntu Linux myself. Setting the "root" password to the first user's password is default behavior. Technically, there is no root in a default Ubuntu install, you must create it/turn it on.

I believe that Solaris no longer has a root user either (for security), and that you must sudo everything. Someone feel free to correct me (well this is /. I don't have to ask ;)

Re:sudo password

[nrosier]

Solaris still has root but since Solaris 8 or 9 they have RBAC, which is a bit like sudo. Role-Based-Access-Control. You assume a roll which gives you extra priviliges.

In Trusted Solaris they also have root but since this is a high grade security OS, root is not god. You have labels (top-secret, restricted etc... iirc). So you might have root-access on a low level label and not being able to do anything.

Re:sudo password

[Anonymous Coward]

>You assume a roll which gives you extra priviliges.

I assume a croissant which effectively makes me root.

Re:sudo password

[djdavetrouble]

Well I can't find any evidence that it does or does not void your warranty, on apple's own site or google, not even a mention of it. Also, I can't believe that enable root would prevent you from getting hardware replaced. It is a normal system function, and there are no warnings to that effect when you do enable the root user (WARNING ENABLING THE ROOT USER WILL VOID YOUR WARRANTY, that sort of thing). It just sounds preposterous, imagine:
You: My hard drive is fritzed, the s.m.a.r.t. diagnostics indicate a hardware failure.
Apple: Is root user enabled?
You: Yes, I am an old skool unix geek that has to have a terminal with '#' open at all times when I am at my system, along with my case of mountain dew and tub of beef jerky.
Apple: Sorry then, enabling root user voids your hardware warranty.
You: But I have to test out this rm -Rf / thingy
Apple: Not on our dime, you root abuser. Use sudo instead after you have purchased a new hard drive.

My guess is this is a lie that someone perpetuated to get some n00b to keep from (unwisely) enabling r00t.

Re:sudo password

[djdavetrouble]

Depends on char race and class. You should chose a human valkyrie for your role based access account, if you want high strength. If you come across Mjollinir, you can throw it and it comes back to you (with 25 strength or higher), plus lightning damage.

Earlier in the game, Magicbane will serve you better (magic resistance, engraving, and curse resistance).

Re:sudo password

[surprise_audit]

Sounds like they're finally catching on to Multics-type security from back in the 80s, where you could own a file, have read/write access, and still not be able to touch it if it was created in a different privilege level...

Yes I rta

[n54]

Talk about trying to kill a simple joke, for all the braindead: it's the intention of the commands that is funny, not typing the command (well that too if it would work but only del *.* in real dos works and that was pretty much the original joke I guess).

To remove this comment press F4 on windows...

And FP btw

Re:Yes I rta

[wdd1040]

del *.* isn't the proper command. deltree /y *.* is. del *.* wouldn't delete the directories recursively it's be like rm -f /.

rm -Rf / and format c: are not the same.

[jellomizer]

rm -Rf / removes all the files mounted on the file system. format c:\ rewrites a new file allocation table.

The issue of Linux not running as cleanly after all the files are whiped out vs. Windows still able to run isn't much a means of stability. Remember in Linux/Unix systems, Everything is a file. While in windows it is some hodgepodge framework where some are files and other are not. So naturally if you wipe out all the files on a Linux/Unix system problem will happen. While windows which puts a lot of its features in memory and stayes there so it can still operate even after you logout. In some ways having X windows crash after you try to leave is a good thing because you know that something is wrong sooner. vs. Windows just acting like nothing happend.

Re:rm -Rf / and format c: are not the same.

[Mordaximus]

Author acknowledges this too, a quick RTFA shows : "I decided to attack Windows from the same attack point as I was hitting Linux. Instead of trying to do a low level erasure of my files I was just going to recursively delete them. So after a little mucking around at the command prompt, I came up with "del /F /S /Q *"."

Re:rm -Rf / and format c: are not the same.

[a_hofmann]

Actually the situation is different than you describe it, as "everything is a file" would generally also hold true for Windows from the file system perspective. Both Linux and Windows load data from a file to memory and keep it there while being in use. Swapping may apply but you can think of the file being wholly in memory.

The difference lies in the ownership design, wherein Windows locks a file when it is opened and leaves it at that until closed. Linux, on the other hand, works with the current snapshot of the file.

File locking is a good thing in the demonstrated situation, as graceful error recovery is important. IMO this case shows the very reason for it being implemented in Windows. Most Windows users have administrator privileges which allow them to delete files they shouldn't be able to, while Linux uses a more strictly separated user concept where regular users are not able to delete crucial system files.

While sometimes file locking is necessary (and in the UNIX case has to be done manually), general file locking is not a good thing because it prevents live system updates. This is why you can update your whole Linux system (besides the running kernel) without rebooting, a thing impossible for Windows installations.

Re:rm -Rf / and format c: are not the same.

[Rich0]

Just a little clarification for the sake of readers who don't know anything about unix file unlinking.

If you use unix/linux, try this experiment:

Create a file foo.txt. Open it with an editor.

Now, from a separate shell, rm the file.

The editor can still save changes. As soon as the editor exits, the file will be completely deleted. I'm not sure about current versions of linux, but in the past at least you could do an ls -a of the directory containing the file and see a hidden file with a random name which contained the file's contents.

In unix, the rm command unlinks a file. That is, it removes its directory entry. If there is another hard link to the same file, it will not be deleted. If there is a file descriptor linked to the file, it will not be deleted.

As soon as the last link is destoryed and there are no open file descriptors for the file, it gets deallocated on the disk.

Personally, I like the linux way - it lets me backup open software, the kernel, the X server, whatever. On windows, backups tend to miss critical files like the registry, OS files, etc. I'm sure commercial backup software use some sort of trick to get around some of this, and other utilities require booting from CD so that the files aren't in use in the first place. I've found the best way to backup windows profiles is to have them roam from samba shares and then back them up in linux, which doesn't care who has the file in use...

Re:rm -fr /

[Zork the Almighty]

You never know - he might do it. This time he has popular support.

Try it with NFS...

[skroz]

I once saw an errant script run as a cron job (I DIDN'T WRITE IT, DAMN IT! WHY DON'T PEOPLE BELIEVE ME!!!) execute "rm -f *" in root AS root once. No big deal, right? What if someone accidentally (IT WASN'T ME!!!) created a file called "-r" in / two years prior to the errant rm? Hmm? Now what happens if you have nearly two terabytes of data mounted rw without root squashing via NFS on that workstation? Now what happens if that runs on a Saturday night and nobody notices until Monday morning?

I'll tell you what happens. What happens is that the next several days are very, very, very long and very, very, very uncomfortable.

Re:Try it with NFS...

[Anonymous Coward]

I once saw an errant script run as a cron job (I DIDN'T WRITE IT, DAMN IT! WHY DON'T PEOPLE BELIEVE ME!!!) execute "rm -f *" in root AS root once.

I once saw a script that had "rm -rf $(FOODIR)/*".

No problem in that. Except that one adminstrator run it as a root and nobody had thought to define $FOODIR for root...

Re:Try it with NFS...

[ajs]

Along similar lines, a co-worker at one of my recent jobs had installed a machine for one of our remote users. He mounted the file-server's storage array directly in order to create the user's home directory. Unfortunately he did 3 things wrong:

1. He left the root of the storage array mounted
2. He left it mounted under /tmp
3. He left the tmp-cleaning cron job enabled

When we started to see user file go away (but directories left intact) we thought we were under some kind of attack... we were right in a way ;-)

Re:Try it with NFS...

[Rostis]

I've seen a similar problem with the solaris admintool. One employee created a user but accidently hit space before the username, realized the mistake and deleted the user again with the admintool. (And no, it wasn't me, I don't use that buggy admintool) :)

The admintool quickly does
rm -rf /home/ username

After that, everyone just went home for the day.

Re:Try it with NFS...

[ticktockticktock]

I think the original poster is talking about a script that failed to escape the filenames or failed to use, what I call, "end of command line options" (or "what is after this is a non-option") command line option (two dashes) before passing the filenames straight to that command. If a file name or folder name is "-r" (at least in SuSE Linux 9.0 with bash 2.05b), and you do rm -f * without using "--" before the asterisks or without properly escaping the filename list, rm indeed does process it as if you wanted it to wipe all directories recursively.

Re:Try it with NFS...

[jeremyp]

Just tried it on my Mac OS X box and the -r was not deleted but everything else was including directories.

It all depends on whether the file "-r" is first the collating sequence. When I added a file called "+r", the -r was treated as a regular file rather than a switch.

Re:Try it with NFS...

[cortana]

Save Shell Programming, Lesson 1!

Use the -- argument to indicate that all following parameters are filenames, and are not to be parsed as options:

rm -f -- *

text

[Anonymous Coward]

format c:

There's a nerdy idea floating around that you can tell an uninformed Windows user to type "format c:" in the Run dialog to solve their problems. This is perpetuated in office jokes and comics among other places, but how many people have actually tried to destroy their using "format c:".

I made a goal for myself to find out what would happen if I ran "format c:" on a freshly installed Windows system and decided to compare it to the equally notorious "rm -Rf /" in Linux. Besides noting how effectively I could trash the system, I wanted to see how the operating system responded, and what it took to be able to destroy the system. I know that "format c:" and "rm -Rf /" aren't equivalent, but they usually are interchangeable punchlines to jokes, which is why they were chosen.

Read more for the destruction of two perfectly good operating system installations.

My target OSes were Windows XP Pro and Ubuntu Linux, both with all the latest and greatest updates. The installs were both fresh and no additional security settings had been set. Ubuntu asked me for a password during installation, Windows did not, which we will see makes a difference later down the line.

First I established a baseline for my environment: a virtual shell parked at the root of the file system (C:\ for Windows, / for Linux).
Windows Linux

Larger Image Larger Image

Well, that was simple enough. Getting to each file system's root was a nearly identical process. Now is where things will change, however. In Windows, I am going to attempt to format the drive, a low level operation which usually occurs on drives not being used and in Linux I am going to attempt to remove all of the files from the filesystem. Both should give me an empty file tree when I'm done, but come at it from different angles. In Windows, I use the "format c: /FS:NTFS" command, in Linux "rm -Rf *".
Windows Linux

Larger Image Larger Image

Thankfully, and as I expected, neither of these commands wiped out my filesystem. To my shock, Windows looked as if it was going to comply with my wishes. It asked me if I would like to proceed and I confirmed that indeed I would. Ah, but as I expected, the drive was mounted and could not be formatted until it was unmounted; so I told it to try to forcefully unmount the drive. Finally it told me that it could not gain sole access to the drive and would not continue. So, straight away "format c:" will not erase your hard drive! Now how did Linux fare? Also, as I expected, almost nothing was deleted by my "rm -Rf *". My personal home directory (~/jonathanhohle) might have been erased, I didn't think to check it before I moved on. All in all, however, both systems were still up, stable, and in need of more abuse!
Windows Linux

Larger Image Larger Image

Larger Image

Larger Image

My goal was to mass erase these disks from the command line and so far I hadn't had much luck. With Windows I knew I was going to have to take a different approach, with Linux, I knew exactly what I had to do to kill this system.

I decided to attack Windows from the same attack point as I was hitting Linux. Instead of trying to do a low level erasure of my files I was just going to recursively delete them. So after a little mucking around at the command prompt, I came up with "del /F /S /Q *". Linux was a no brainer. All I had to do was escalate my permissions with sudo, "sudo rm -Rf *" to be exact.
Windows Linux

Larger Image Larger Image

Well, that did the trick on both systems with one caveat. As the first Linux screenshot under this paragraph shows, Linux would not continue with the command until the root password was entered. Windows, on the other hand had no problems going to town unlinking files after the [Enter] key was struck.
Windows Linux

Larger Image Larger Image

Afte

slow?

[miyako]

I thought it was pretty interesting that it took so much longer to delete everything under windows/NTFS. Anyone know why this is (is NTFS slow, or is it the del command as the author guessed, or is there some other reason for this).

Re:slow?

[Pedersen]

Anyone know why this is (is NTFS slow, or is it the del command as the author guessed, or is there some other reason for this).

Actually, a big chunk of this is screen I/O. The fix? Instead of using del (which likes to print out the names of all files it deletes), use rmdir /s /q. It goes much much faster (and yes, this is speaking from experience, though good experience, for a change).

Re:slow?

[blether]

You can also speed it up by minimizing the window so that the screen isn't being updated.

Get a life

[soul_hk]

Seriously folks,
this proves almost nothing.
This guy really needs to find something better to occupy his time with, ideas include polishing the spoons, re-arranging the sock drawer and cleaning the fridge.

We all know the best way to screw a Windows XP SP2 user is to convince them to turn off the firewall ..

mod me down, see if I care

Re:Get a life

[The Angry Mick]

We all know the best way to screw a Windows XP SP2 user is to convince them to turn off the firewall .

Some might argue that simply having Windows XP means the users have already screwed themselves.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:rm -fr /

[Jogar the Barbarian]

He's got my vote!

Now pass the freedom fries!

Shred

[Ann Coulter]

I like to use "shred /dev/hda". That takes time but it is worth it if you know you will never use that hard drive again, such as when you leave a company. If you are in a pinch, you can first do a "cat /dev/zero > /dev/hda". You can also use "dd" or "sdd". If you want to erase a magnetic medium, zero out the media first and then use "shred".

Re:Shred

[ticktockticktock]

You could also stick in Darik's Boot and Nuke, provided you want to wipe ALL drives connected to your system and don't have anything you need to backup on them.

Re:Shred

[LeninZhiv]

Note that (unless you're shredding a device file as in parent, presumably) you shouldn't shred files using a journalled file system. From the man page (for version 5.0.91):

CAUTION: Note that shred relies on a very important assumption: that the filesystem overwrites data in place. This is the traditional way to do things, but many modern filesystem designs do not satisfy this assumption. The following are examples of filesystems on which shred is not effective:

* log-structured or journaled filesystems, such as those supplied with AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.)

* filesystems that write redundant data and carry on even if some writes fail, such as RAID-based filesystems

* filesystems that make snapshots, such as Network Appliance's NFS server

* filesystems that cache in temporary locations, such as NFS version 3 clients

* compressed filesystems

Re:Shred

[hacker]

"There is quite a hell of difference between being able to read the unlinked but otherwise unharmed data and having to gut the disk to put it into some specialistic tool."

Gut the disk? Surely you jest. I've personally done security forensics on many recovered drives in S&S raids, and there are a lot of amateur techniques attempted to "erase" data. Most of them don't work. Unless the actual drive electronics are damaged, you don't have to "gut the drive" to get the data back, up to 7 low-level formats deep.

If the drive has had other measures taken to erase, destroy, or obfuscate the data, you might have to pull off platters and cleanroom the drive, but that is very very very rare.

Its as simple as booting to clean media, duplicating the drive, and pulling the data out, with tools as simple as using 'ls'. They may not be openly available to the public, but these tools ARE available to professionals in the security industry.

The other interesting tidbit, is that almost all people who erase their data partitions to try to "erase their tracks", ALWAYS forget to do the same thing to the swap partition or files. OOPS!

deltree

[cbr2702]

I'm pretty sure they removed deltree from winXP.

Re:deltree

[another_henry]

They did, but you can replicate the behaviour with

RD /S

Also,

DEL /S

has a similar but not identical effect.

rm -Rf /

[Savage-Rabbit]

I once watched somebody do that while logged in as root on a unix machine. The guy was a really fast typist with an ushakable faith in his ability, before I had a chance to stop him he had managed to type and commit the command:

root@localhost# rm -rf / somedir/somesubdir

instead of:

root@localhost# rm -rf /somedir/somesubdir

That inadvertent space made all the difference. Fortunately we had a very good backup system.

Re:rm -Rf /

[Sentry21]

Seen in a makefile in comp sci class:

clean:
rm -rf *.o *~ /* Remove all temp files */

Fortunately, the kids weren't running as root. They DID have to re-do their project afterwards though. Handy tip, don't use -r unless you REALLY need to. Accidents make it disastrous.

--Dan

Re:rm -Rf /

[dr_d_19]

We had a large collection of .cfg-files in directory in which I was working. Also, whole lot of left-over files (from our inhouse editor utility) which had no "file ending".

So, there I was, late at night, getting tired of all those #%!&/#!%# backup-files.

Since I wanted to keep my .cfg's, I typed:

rm -rf . *

Which, of course, was wrong. What I wanted was:

rm -rf .*

While the parent post had backups - and I was absolutely certain we had them too - we did not.

That was a loooong week :)

Go away, you don't exist

[Anonymous Coward]

was the message I got after trying to logout of a similarly trashed Debian Woody system.

rm -rf / protection in Solaris

[colores]

From: "Solaris 10 has (since build 36) a version of /usr/bin/rm (/bin is a sym-link to /usr/bin on Solaris) and /usr/xpg4/bin/rm which behaves thus: [28] /bin/rm -rf / rm of / is not allowed [29]"

I've seen that image before...

[Shambhu]

... this one, I mean. And I'm convinced it is one of those Magic Eye things.

The most beautiful of all solutions

[oakad]

>su >dd if=/dev/zero of=/dev/hda Works every time for me!

Re:The most beautiful of all solutions

[Greyfox]

Oddly enough, that DIDN'T work for me once. At that point I started to get suspicious...

A couple months ago I bought a new system and after I got done transferring my files I gave my room mate my old drives. One of them worked OK on her Windows system for all of about 3 days, then she tells me that her friends who provide her Windows support though I was some sort of IT God because I'd set Windows up so that they couldn't delete the files on that drive, even with admin support. I disclaimed all responsibility, saying that I'd just gone through the install normally.

Well after another few days her friends had thrown their hands up saying they couldn't do anything with the system. At this point we decided that something they'd done probably hosed the system up, so we decided to reinstall Windows. Only the windows install fdisk and format didn't seem to want to touch the drive either.

Still not trusting Microsoft, I fired up a knoppix CD and went after it with the linux fdisk. No dice. Finally I did a dd if=/dev/zero of=/dev/hda. And THAT didn't work.

"Inconceiveable," I said to myself but I had one weapon left in my arsenal. I popped out to Maxtor's web site and downloaded the low level format utility for that type of drive. Now this was the first time I'd ever low level format an IDE drive, so I was quite excited. I fired it up and let it go. And THAT didn't work. So I decided that the drive was no longer capable of being written and removed it from the system.

The funny thing about this while mess (Other than me wasting about a week on the system) was that no one ever indicated that there was any error writing to the drive, and it actually looked like data on the drive was changing up until the system was rebooted. All I can think is that the data was being changed on an on-disk RAM buffer on the drive, but that the drive's physical ability to be written no longer existed. Even my attempt to low-level format the drive looked like it was working right up until I rebooted the system.

Then why not use the proper syntax?

[lakcaj]

It amazes me how often I see people trying to seem 7331 by saying shit like, "Just rm -rf /" and laughing their heads off.

I'm not even a system administrator, but even I know that any admin worth their salt knows to type the flags after the destination, ala:

rm / -rfv

or

rm /etc/somefile -rfv

This way, if you accidently hit return before typing the full path, you will be prompted for confirmation, since you didn't get to the part where you type the "-f" flag.

The medium tech solution

[Anonymous Coward]

Microwave the drive... works everytime. If the room is dark, you're in for watching some serious fireworks!

When ls is hosed...

[ccarr.com]

...use the shell's built in file expansion:

echo *

Re:When ls is hosed...

[dbIII]

If vi still lives you can also use that as ls (used it that way on dodgy disk mirror that corrupted both disks).

Re:When ls is hosed...

[bryhhh]

Interesting, damn it - where are my mod points when I need them.

I could have done with tip that a few weeks ago. The UK TiVo has a serial port on the back which allows you to get a bash shell, unfortunately there is no 'ls' on the damn thing, so I ended up using 'file ' to get a directory listing.

Just for info, echo */ will list only the directories.

dissecting frogs..

[mks113]

Humor can be dissected as a frog can, but the thing dies in the process and the innards are discouraging to any but the pure scientific mind.
E. B. White (1899 - 1985)

Unix file philosophy

[BlueWonder]

It seems that the author misunderstands an important part of the Unix philosophy:

Linux, however, loads programs into memory and doesn't worry about locking them, so nearly everything was removed, even programs that were currently running when I removed them.

That's far from true. Linux locks the executable file, i.e. if you attempt to open it for writing, you get an error. You can, however, remove the directory entry, in which case the file is retained as long as the program is still running.

Under Linux, a file can have zero, one, or more directory entries (a.k.a. hard links). It's not possible to remove files, only directory entries can be removed. The kernel removes the file automatically once two conditions are fulfilled:

1. No directory entries point to the file.
2. No processes have the file opened.

In fact, under Linux the /proc filesystem allows it to get the contents of an open file back even if it has no directory entries outside of /proc.

Re:Unix file philosophy

[nilsjuergens]

1) Quickly and silently removing the file, while leaving access hidden inside a link in the /proc filesystem

The Unix Way

2) Failing to remove the file (because you're using it right now) and informing you

The Windows Way, also known as "please reboot for the changes to take effect"

The OS really really should _not_ try to second-guess whats wrong or right, just let the user do it. The running application may still enforce certain rules if it has to.

Re:Unix file philosophy

[blether]

You can't use the same technique on Windows but there is an equivalent technique: rename the running exe or dll and copy in the new one.

You still have to stop and restart the process for the update to take effect.

If a sofware update on Windows requires a reboot it's because the author made it that way, not because Windows requires it. The differences are cultural rather than technical.

Re:Unix file philosophy

[BlueWonder]

Which is better:
1) Quickly and silently removing the file, while leaving access hidden inside a link in the /proc filesystem
2) Failing to remove the file (because you're using it right now) and informing you
?

1) is better, and it would be better even if /proc didn't exist. There is no reason why every file must be accessible through a directory entry.

Without this mechanism, it would be impossible to replace the directory entry corresponding to an open file atomically, which is a prerequisite for updating running executables or shared libraries.

I reckon removing a file should be harder if it's currently being used.

As I explained, removing a file which currently being used is not only hard, but impossible. Only the corresponding directory entries can be removed.

Re:Ok

[torpor]

Its not so hard to run either windows/DOS or linux in a VM with debug/trace turned on, logging all, for analysis. Its not something that 'takes a lot of time', just a bit of effort.

the beautifulness of this article (which i haven't read) is that it (probably) frames the difference between two OS's on the basis of 'stupidest luser thing to type', and thus is interesting to .. guess i'll go read the article now..

In the good old days

[argent]

Back in the '80s, my boss had one of the first PCs in the building with a hard disk. One day he asked me to copy some files off onto a floppy, so I put the floppy in the drive and typed "format", as I was used to doing...


C:>FORMAT
Insert floppy into drive C: and hit return.


The rest is history. As was everything on the drive.

Kerry and Bush systems

[LINM]

I tried some similar expressions recently:

format c: /FS:KERRY
rm -Bush *

The results were very telling. Both candidates made about 5,000 prompts all on the order of "5 more years?:" and "The American people will pick the right man for 5 more years?:". As most of these prompts were gibberish, I responded in a random fashion.

In the end, the files of the Bush system remained on the system, but still functioned poorly and continued to periodically core dump.

What amazed me on the Kerry system was that the files actually wrote over themselves many times before all simultaneously deleting!

All in all, the process took about 7 months and I can honestly say that I hope never to have to do that again. Further more, based on how both operate when active, I would like to see a completely new category of OS if I do have to go through this again.

ls

[szo]

He notes that "dir" is a built-in and "ls" is an external, so he could get a directory in windoz, but not on linux. Thats wrong, he could have used "echo *" on linux to get the directory listing.

Szo

I hate the finnish keyboard layout

[jahalme]

Typing the tilde character on a finnish keyboard is just plain stupid. You have to first hold AltGr and press a key to the left to enter, underneath backspace, then release both keys and press space. Insanity!

Ok, I've just finished installing Linux on a fresh hard drive and have spent a few hours editing stuff in /etc using my favourite editor joe. The editor creates backup files everytime it overwrites a file, naming them as the original filename with a tilde appended. I wanted to quickly remove all the backup files so I typed

rm -f *~

But curses, my caffeine-overloaded fingers were too quick to hit that spacebar and I ended up with

rm -f * ~

AARGH! There goes BOTH /etc AND root's home directory. Damn you whoever came up with the finnish keyboard layout!

Re:rm *

[julesh]

Cause wildcards aren't actually recognised by the kernel. It's entirely up to your shell what characters are used as wildcards, so why should the kernel discriminate against weird shells by only recognising the wildcards used by the bourne and C shells? Or should they just outlaw anything that might be a wildcard? What if I wrote a shell that used 'e' as its wildcard? :)

Mirrordot

[Metteyya]

Site was /.-ed (well, what a surprise). Please, use MirrorDot. This particular story (with full images) can be found under this link. Anyway, the comparison is good. But how about comparing mkfs with format c:?

not as thorough as...

[catdevnull]

These methods are pretty good ways to kill a system. However, I found that a large electromagnetic field generated by an old bulk eraser produces similar results in just seconds! Man, was my cube mate pissed!

I don't have screenshots, though. I think I'm sterile, too.

NTFS is much slower then EXT3 ???

[ltwally]

In his conclusion Jonathan claims that EXT3 is faster than NTFS ...

"NTFS is much slower then EXT3"

I believe he is wrong. Firstly, everyone knows how dogg slow EXT3 is at just about everything. ;) ... But more importantly I notice that he seems to be doing all the work from a windowed command prompt. Normally you wouldn't see that as a problem... however, I have noticed on several occasions that when text is rapidly scrolling accross the screen, the command prompt hogs the CPU -- to the point of dragging out whatever operation you're doing to several times the necessary length of time.

There is an easy fix for this -- just don't have massive amounts of text scrolling through a windowed command prompt; minimize the window, pipe the text to a file, or even make the command prompt full screen. Any of the above tricks will dramatically speed things up, as the CPU is no longer spending large amounts of its time writing text to the screen.

If anyone out there is feeling adventurous (or insane), go ahead and try to replicate Jonathan's test -- only don't leave the command prompt in windowed mode. Minimize it or redirect the text. I'd bet you my ex-girlfriend's right arm that NTFS is suddenly as fast as, if not faster than, EXT3.

*boggle* who uses -R

[jhill]

I don't know about you, but I believe in the sysadmin credo, do as little work as possible.

Therefore, any competent sysadmin would never use rm -Rf, they'd use rm -rf, that R takes a lot of effort for me to move my pinky to the shift key.

*sheesh*

Re:How did he start Gnome?

[Moloch666]

He was already in Gnome

A Fun Game!

[Robmonster]

We used to login as root and type 'rm -r' into the console WITHOUT pressing Enter.

We then took turns at throwing stuff at the keyboard to see if we would just-so-happen to hit the Enter key.

Luckily, none of us were very good shots...

RM

Commands from the wrong era!

[crath]

The problem with the tester's premise is that he is from the wrong era. These punch lines originate from 20 years ago. In those ancient days of computing, the commands did indeed allow a user to effectively (in the case of UNIX) or completely (in the case of MS-DOS) wipe out their file system.

I speak from personal experience on both OSes; 20 years ago, when both OSes were still young.

A fair test of these punch lines can only be executed on MS-DOS 1.x and on one of the *many* UNIX varients from the mid-1980s.

... or errant symlinks

[achurch]

Along the same lines, I had at one point a link "~achurch" in my public_html directory, for compatibility after my homepage changed URLs. So (you can guess what comes next, I'm sure) I decided one day, several years later, to clean up my web stuff:

$ rm -r tmp/ x.html [...] ~achurch/
rm: override permissions 000 for /home/achurch/.xcdroast? _

I have no idea why mny .xcdroast was 000, but it saved me a huge amount of frustration. I now place a file "..norm-r", mode 000, in important directories and rename things around to make sure it's always first in the directory file. And I never, ever use -f.

I laugh at your format...

[torrents]

You want your data really gone... Follow these rules... The DOD rules for HDD disposal. 1. Triple Overwrite security erase. 2. De-gauze with a powerful electro magnet. 3. Crush drives with a cement roller. 4. Melt fragments into slag. 5. Bury Slag in a secure waist disposal site under a minimum of 6' of cement.

Nothing hides evidence like a stew.

[infonography]

simmer your drive for 40 minutes on high heat till tender. Add taters, carrots, celery. spices. Remember to Floss now.

This aint SCIENCE...

[Ancient_Hacker]

A very unbalanced comparison:

Format c: is more analogous to mkfs /dev/sda0

rm -Rf / is more like deltree c:

and IIRC the Windows del command waits 5 seconds on each busy file before giving up the delete, making NTFS deletes on busy files seem very slow.

Let's at least do our meaningless comparisions correctly!

Interesting error messages

[Denis Lemire]

I once did a recursive rm -rf / as root on Slackware linux. After it completed I tried to log out and all I got was a message that said:

"You don't exist, go away!"

Very amusing.

Anybody know which Linux package is responsable for this message?

Re:Interesting error messages

[evilviper]

Anybody know which Linux package is responsable for this message?

It doesn't exist. Go away.

Re:openbsd rm and journalled filesystems

[ajs318]

You can unmount an ext3 file system, and remount it as an ext2 file system. Then you'll get known in-situ overwrites. But if you didn't increase the length of a file, there's no reason for the OS not to write it back right where it used to be, so sync ought to force it to complete the operation. Although some of the writes may be optimised away.

And I'm not so sure about the viability of recovering overwritten data anyway, even with electron microscopes and whatnot. Let's face it, if it was at all practical, someone, somewhere would have used the techniques to build a high-capacity drive that worked by storing new data "over the top of" old data, and there'd be a fanfare of press releases about it -- and no end of debate on Slashdot over whether the patent was enforcible.

Microscopic techniques might have worked once with low density devices, but today's drives can easily pack 2000x as much information into the same amount of space as was common just 10 years ago. It's my assertion that all claims regarding the recoverability of overwritten data are hopelessly exaggerated if not absolute bullshit. I'd like to see a proper scientific study, but I have a feeling there are more compelling reasons not to do one ..... For one, the authorities would like to pretend they can recover data even if they couldn't {even if only to give plausible deniability to some of their operations; they'd prefer you to think they got that data from your used hard disk than to find out how they really got it}. For another, HDD manufacturers sell more new units if there aren't so many second hand ones on the market. And for the kicker, if it can be shown that the Government has been needlessly destroying valuable goods bought with taxpayers' money, it's going to be every lawyer's birthday at once.

mkfs won't do the trick, but mkswap certainly will

[lxt518052]

That's because /dev/hda1 is mounted on /.

To verify this, try the following as root. Don't worry, this is safe.

# dd if=/dev/zero of=dump bs=512 count=1000
# mke2fs dump
# mkdir dumpdir
# mount -o loop dump dumpdir
# mke2fs dump

And you shall get this:
mke2fs 1.35 (28-Feb-2004)
dump is not a block special device.
Proceed anyway? (y,n) y
dump is mounted; will not make a filesystem here!

However, if you issue a
# mkswap dump
You'll be happily notified:

Setting up swapspace version 1, size = 507 kB

Done. ;)

Restoring a partially deleted root file system

[binux]

This usenet article on how a partially deleted filesystem was restored with some ingenuity makes an interesting read.