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

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

[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

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

Slashdotted, mirror:

[Anonymous Coward]

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

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.

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

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 ;)

Comment removed

[account_deleted]

Comment removed based on user account deletion

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.

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

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.

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

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

[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

[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

[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

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