Shootout: 'rm -Rf /' vs. 'Format C:' 513
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."
openbsd rm (Score:5, Informative)
Slashdotted, mirror: (Score:3, Informative)
rm -Rf / and format c: are not the same. (Score:4, Informative)
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.
text (Score:5, Informative)
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
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:
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
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 (Score:5, Informative)
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
Comment removed (Score:3, Informative)
Shred (Score:5, Informative)
Re:rm -Rf / and format c: are not the same. (Score:5, Informative)
deltree (Score:3, Informative)
Re:deltree (Score:5, Informative)
Re:openbsd rm (Score:5, Informative)
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:Try it with NFS... (Score:2, Informative)
Re:rm -Rf / and format c: are not the same. (Score:5, Informative)
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:Shred (Score:2, Informative)
Unix file philosophy (Score:5, Informative)
It seems that the author misunderstands an important part of the Unix philosophy:
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:
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:Shred (Score:2, Informative)
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:sudo password (Score:5, Informative)
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 (Score:1, Informative)
war is peace
compasionate conservative
election results
Re:openbsd rm (Score:5, Informative)
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:you know (Score:1, Informative)
Re:Try it with NFS... (Score:3, Informative)
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:slow? (Score:4, 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).
Mirrordot (Score:2, Informative)
NTFS is much slower then EXT3 ??? (Score:5, Informative)
I believe he is wrong. Firstly, everyone knows how dogg slow EXT3 is at just about everything.
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:When ls is hosed... (Score:3, Informative)
Re:When ls is hosed... (Score:3, Informative)
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... (Score:5, Informative)
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? (Score:2, Informative)
Re:Shred (Score:3, Informative)
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!
Re:Automatic format of c:\ (Score:1, Informative)
format c:
achieves the same result. It was undocumented.
I laugh at your format... (Score:2, Informative)
Re:slow? (Score:2, Informative)
This aint SCIENCE... (Score:2, Informative)
Format c: is more analogous to mkfs
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:Unix file philosophy (Score:2, Informative)
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:rm -Rf / and format c: are not the same. (Score:3, Informative)
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:you know (Score:1, Informative)
The president wasn't the only guy up for election yesterday, ya know.
Re:openbsd rm (Score:5, Informative)
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 (Score:4, Informative)
Re:...vs Magnet vs Tossage (Score:5, Informative)
Not in the USA. Trash is considered 'abandonded property' [harvard.edu] and is up for grabs.
mkfs won't do the trick, but mkswap certainly will (Score:2, Informative)
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. ;)
Did you try to use the Windows CD to restore? (Score:1, Informative)
Also, did you try a "restore" from the bootable Windows CD?
Restoring a partially deleted root file system (Score:2, Informative)
Re:...vs Magnet vs Tossage (Score:4, Informative)
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 (Score:3, Informative)
However, the person who posted
was onto something. That killed the machine I typed it at
Re:...vs Magnet vs Tossage (Score:4, Informative)
Platters aren't metal.
Re:...vs Magnet vs Tossage (Score:4, Informative)
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:openbsd rm (Score:4, Informative)
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.
Re:...vs Magnet vs Tossage (Score:3, Informative)
Or, better:
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 (Score:3, Informative)
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...