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

...vs Magnet vs Tossage

[molywi]

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

The medium tech solution

[Anonymous Coward]

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

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

[Bertie]

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

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.

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

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

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' [harvard.edu] and is up for grabs.

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,

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

[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

[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

[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

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

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

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

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

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

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

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

[miyako]

actually, I think they should have replaced the "format c:" with "Deltree /y c:\*", because even the most inept tend to know that "format" will hose their drives.

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.

Re:A more appropriate shootout

[DarkSarin]

I was thinking the exact same thing--trouble is, most people don't really know about either (of course the ones who don't probably don't know about rm -rf either).

Stupid clueless users.

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

[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 [dealsites.net]

Before they got slashdotted..

[pigeon]

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

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

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

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

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

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

[account_deleted]

Comment removed based on user account deletion

google cache link.

[bagel2ooo]

http://66.102.7.104/search?hl=en&lr=&q=cache%3Ahtt p%3A%2F%2Fhohle.net%2Fscrap_post.php%3Fpost%3D23%2 6m%3Dfull&btnG=Search

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 wh

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

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

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

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.

About that

[Underholdning]

The site is gone, but I read the text from Googles cache. [google.dk]
I don't find it interesting though. What's next, comparing PS2 to Xbox by hammering them with a brick and see how much damage is made?

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

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.

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

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

More efficient way

[yehim1]

Try this for almost the same effect but a very small fraction of the time:

# rm -rf /etc

I have did this (twice) by trying to delete something in /etc, but pressed return too quickly. By the time I pressed CTRL-C, every file in /etc is already blanked out!

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 /

[bersl2]

user@localhost:~ $ rm /mnt/floppy/ *

I wanted to kill myself after that one.

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

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: [sun.com] "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]"

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

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

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!

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.

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.

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.

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:rm -fr /

[nounderscores]

For a second I read that as

rm .fr

as in "remove france"

Re:rm -fr /

[Zork the Almighty]

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

Re:rm -fr /

[Jogar the Barbarian]

He's got my vote!

Now pass the freedom fries!

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

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 responsibi