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

openbsd rm by Anonymous Coward · 2004-11-03 00:11 · Score: 5, Informative

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

Re:openbsd rm by Ice_Balrog · 2004-11-03 00:36 · Score: 5, Informative

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.

--
#include "sig.h"
Re:openbsd rm by dukerobillard · 2004-11-03 01:18 · Score: 5, Informative

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 by greed · 2004-11-03 04:20 · Score: 5, Informative

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 by zarthrag · 2004-11-03 04:27 · Score: 3, Informative

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.

--
Why can't all fpga/microcontroller manufacturers just release free optimizing compilers???
Re:openbsd rm by alangmead · 2004-11-03 11:58 · Score: 3, Informative

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: by Anonymous Coward · 2004-11-03 00:13 · Score: 3, Informative

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

rm -Rf / and format c: are not the same. by jellomizer · 2004-11-03 00:17 · Score: 4, Informative

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.

--
If something is so important that you feel the need to post it on the internet... It probably isn't that important.

Re:rm -Rf / and format c: are not the same. by Mordaximus · 2004-11-03 00:24 · Score: 4, Informative

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. by a_hofmann · 2004-11-03 00:52 · Score: 4, Informative

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. by Rich0 · 2004-11-03 03:26 · Score: 2, Informative

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

text by Anonymous Coward · 2004-11-03 00:17 · Score: 5, Informative

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 by _Hellfire_ · 2004-11-03 00:20 · Score: 4, Informative

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

--
"And then I visited Wikipedia ...and the next 8 hours are a blur..."

Comment removed by account_deleted · 2004-11-03 00:21 · Score: 3, Informative

Comment removed based on user account deletion

Shred by Ann+Coulter · 2004-11-03 00:24 · Score: 4, Informative

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 by ticktockticktock · 2004-11-03 00:55 · Score: 2, Informative

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 by LeninZhiv · 2004-11-03 01:01 · Score: 2, Informative

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 by hacker · 2004-11-03 02:53 · Score: 2, Informative

"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 by cbr2702 · 2004-11-03 00:25 · Score: 2, Informative

I'm pretty sure they removed deltree from winXP.

--

This post written under Gentoo-linux with an SCO IP license.

Re:deltree by another_henry · 2004-11-03 00:28 · Score: 4, Informative

They did, but you can replicate the behaviour with
RD /S
Also,
DEL /S
has a similar but not identical effect.

--
"Studies have shown that people who eat peanuts live longer than those who do not eat."

Re:Try it with NFS... by ticktockticktock · 2004-11-03 00:50 · Score: 2, Informative

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.

Unix file philosophy by BlueWonder · 2004-11-03 00:58 · Score: 4, Informative

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:

No directory entries point to the file.
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 by blether · 2004-11-03 03:18 · Score: 2, Informative

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:sudo password by nrosier · 2004-11-03 01:05 · Score: 5, Informative

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.

2004, 20 years late by Anonymous Coward · 2004-11-03 01:15 · Score: 1, Informative

laughing is crying
war is peace
compasionate conservative
election results

Re:you know by Anonymous Coward · 2004-11-03 01:26 · Score: 1, Informative

what results?

Re:Try it with NFS... by jeremyp · 2004-11-03 01:35 · Score: 2, Informative

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.

--
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe

Re:slow? by Pedersen · 2004-11-03 01:52 · Score: 3, Informative

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

--

GPL made simple: What was my stuff is now our stuff. If you improve our stuff, please keep it our stuff.

Mirrordot by Metteyya · 2004-11-03 01:57 · Score: 2, Informative

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

NTFS is much slower then EXT3 ??? by ltwally · 2004-11-03 02:12 · Score: 4, Informative

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.

--

/dev/random

Re:When ls is hosed... by dbIII · 2004-11-03 02:18 · Score: 2, Informative

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... by bryhhh · 2004-11-03 02:22 · Score: 2, Informative

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.

Re:Try it with NFS... by cortana · 2004-11-03 02:24 · Score: 4, Informative

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:How did he start Gnome? by Moloch666 · 2004-11-03 02:24 · Score: 2, Informative

He was already in Gnome

--
Understanding is a three-edged sword. -- Kosh Naranek

Re:Automatic format of c:\ by Anonymous Coward · 2004-11-03 02:55 · Score: 1, Informative

simply typing:

format c: /autotest

achieves the same result. It was undocumented.

I laugh at your format... by torrents · 2004-11-03 03:07 · Score: 2, Informative

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.

--
Get your torrents...

Re:slow? by blether · 2004-11-03 03:08 · Score: 2, Informative

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

This aint SCIENCE... by Ancient_Hacker · 2004-11-03 03:14 · Score: 2, Informative

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!

Re:you know by Anonymous Coward · 2004-11-03 03:29 · Score: 1, Informative

Maybe the ones where the GOP have definitely and indisputably increased their majorities in both houses of Congress?

The president wasn't the only guy up for election yesterday, ya know.

Re:...vs Magnet vs Tossage by Le+Marteau · 2004-11-03 04:35 · Score: 4, Informative

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.

--
Mod down people who tell people how to mod in their sigs

mkfs won't do the trick, but mkswap certainly will by lxt518052 · 2004-11-03 05:19 · Score: 2, Informative

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

--
People who dislike China tend to mention Tiananmen Square a lot, but they always forget the Tank Man is also a Chinese.

Did you try to use the Windows CD to restore? by Anonymous Coward · 2004-11-03 05:43 · Score: 1, Informative

Did you try to use the Windows CD as the dialog popped up asking for it?

Also, did you try a "restore" from the bootable Windows CD?

Restoring a partially deleted root file system by binux · 2004-11-03 06:14 · Score: 2, Informative

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

Re:...vs Magnet vs Tossage by hazem · 2004-11-03 08:01 · Score: 3, Informative

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:A more appropriate shootout by lakeland · 2004-11-03 10:07 · Score: 2, Informative

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

Re:...vs Magnet vs Tossage by evilviper · 2004-11-03 10:32 · Score: 3, Informative

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.

--
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant

Re:...vs Magnet vs Tossage by hazem · 2004-11-03 10:50 · Score: 3, Informative

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 by mvdw · 2004-11-03 17:43 · Score: 2, Informative

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 by the+narf · 2004-11-04 05:06 · Score: 3, Informative

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

Slashdot Mirror

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

49 of 513 comments (clear)