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

[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.

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

[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

[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.

A more appropriate shootout

[cyborch]

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

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.

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

[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.

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.

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...

[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...

[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

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

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: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.

Go away, you don't exist

[Anonymous Coward]

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

When ls is hosed...

[ccarr.com]

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

echo *

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.

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!

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.