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

skyshock21 writes "There's an article over at hohle.net about what actually happens when you type the commands Format C: in windows versus rm -Rf / in Linux. Very interesting results indeed. Myths are busted, and hilarity ensues."

Comments

...vs Magnet vs Tossage

[molywi]

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

Re:...vs Magnet vs Tossage

[1nhuman]

Actually a Dutch (national) prosecutor did something similiar a month ago. He thought his HDD failed and put his whole PC with his garbage on the street.

Unfortunatly a Taxi driver took the PC with him and managed to boot the machine and found an enormous ammount of very confidentinial information on the HDD. Information about some top crime and fraude cases. The Taxi driver then sold this HDD to a dutch TV crime fighter.

In the end this got the prosecutor fired. Which I think is sort of unreasonable, since the major issue is the justice departments lack of descent security procedure.

Re:...vs Magnet vs Tossage

[NightWhistler]

The funniest thing was the official procedure recommended for getting rid of the machine: pounding it with a sledge hammer ;-)

Re:...vs Magnet vs Tossage

[Anonymous Coward]

HA!

>departments lack of descent security procedure.

Those scumbags! They're using public money to play mid 90's games on public computers! And without paying attention to the tendinitis problem!!!!

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

[bbc]

Making fun of spelling (especially of that of a non-native speaker) is so last week.

Re:...vs Magnet vs Tossage

[bbc]

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

Depends. Keeping up security is part of his job description. If his tech department had lied about or exagerated the security of using a PC without knowing anything about it, you may be right, but not if the guy hadn't even bothered trying to find out.

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

[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

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

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

[Anonymous Coward]

Not in the USA. Trash is considered 'abandonded property' and is up for grabs.

That, and other courts have said that because the previous owner threw the trash out, it had, by definition, no value and therefore, any taking of the trash could not be considered theft because it had no value to the one who tossed it.

Re:...vs Magnet vs Tossage

[PPGMD]

It's more fun when you bring the whole computer to us.

Nothing like watching a CRT monitor explode to brighten your day.

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. c) If this computer was his own, he was able to take sensitive data away from the office and place it in an unsecure enviroment. Most users don't know that if you delete somethign it is still there. The fact that there isn't a policy for situations like this or that the policy wasn't known by the employies is verry troubling.

On the other hand, this could have been nothing more then a setup to feed information to the tv reporter and the story about setting the computer to the curb because the hardrive was bad could be a failed attemp to cover it up. It would be interesting to find if the guy recieved any types of payments form the television station or any other affiliation associated with that guy.

Re:...vs Magnet vs Tossage

[ThomaMelas]

So you're going to arrest all of the trash collectors? Good call.

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

[Anonymous Coward]

or a nail gun as we did where we work for shits and giggles

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, just went back inside packing readying for the move. Came out with another load of trash to put at the curb...the whole box was gone...hahaha. Was amazed at how fast it went and during the daytime.

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

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

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

[tedhiltonhead]

Interesting. Downside is the limited bitrate of the sound. Assuming CD quality audio, that's only 176,400 bytes per second.

Re:...vs Magnet vs Tossage

[suckmysav]

CRT monitors don't explode, they implode.

Re:...vs Magnet vs Tossage

[Anonymous Coward]

Only newest and largest drives have glass/ceramic platters, most drives still use alumunium or non-ferromagnetic aluminium allow.

Re:...vs Magnet vs Tossage

[Anonymous Coward]

Platters aren't metal.

Are too!

Re:...vs Magnet vs Tossage

[yuri benjamin]

What's wrong with /dev/urandom? Not enough entropy?

Re:...vs Magnet vs Tossage

[Anonymous Coward]

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.

I always dispose of the personal letters and effects and bank statements that people give to me because they are "old" or "broken" without reading them, too!

I guess you haven't seen the laws saying that what you put on your curb for trash is not only no longer your property, but legally admissable evidence for law enforcement to sieze and inspect without a warrant.

Don't bother wiping a drive when you're done with it, because it's a waste of time that won't overwrite remapped sectors anyway. Often drives remap sectors or entire tracks that are perfectly readable but have had too many recoverable(!) errors. Just encrypt everything important on the drive and never let the plaintext touch it. It's much more convincing to have a "normal person" computer drive laying around with an OS and a few dozen random spots or maybe a random partition than a static filled drive with some remapped sectors with porn on them.

Re:...vs Magnet vs Tossage

[Anonymous Slacker]

I took apart a few recently-replaced 3.5" ATA drives a year or two back (did a major, multi-computer upgrade and had some leftovers), ranging from 20 to 40 GB, and took the tin snips to the platters. Most of them cut pretty easily, like thin metal, but the IBM (one of their first 40GB ATA drives from ~2000/2001) platters shattered when I tried to cut them.

Re:...vs Magnet vs Tossage

[iamcf13]

Sad to say, parent is correct.

There is sensitive material on the HDDs as well as 'stored' in the RAM chips and BIOS CMOS on the motherboard and 'burnt into' the phosphorous coating on the CRT. If the computer motherboard, HDDs, and CRT are destroyed, whatever is left could be conceivably recycled into a new system or used as spare parts for existing systems.

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

[ajs318]

Remapped sectors aren't so much of a concern precisely because they've been remapped {hence, hidden from the clueless} and they're only sectors {hence, not likely to be easy to determine much from them ..... even what they're supposed to be part of}.

Encryption, on the other hand, is a good idea. I really wonder why it isn't done in the drive at the firmware level. The key could be on something like a telephone SIM card -- if the card is absent the drive is unencrypted, if it's there then everything is encrypted, but either way it behaves the same as far as the host OS is concerned. The decrypted data is buffered into RAM {and so gets lost with power}. When you replace a drive with a new one, you can put the old keycard in the new drive and can pass on the old drive with the new keycard {or no keycard at all} without fear of anything being discovered that you'd rather wasn't. Although it'd still be worthwhile filling it with encrypted random stuff, just in order to see the look on some poor idiot's face if he thinks he's managed to decrypt it .....

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

Re:...vs Magnet vs Tossage

[rp]

But they do have a decent security procedure, an official from the dept. of Justice explained on TV. It just wasn't followed in this case. The guy shouldn't even have had this stuff on a PC at home. Never attribute to lack of brueaucracy what can be accounted for by arrogance alone.

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

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

Actually, thinking about it, that won't work because when you truncate the file, you're going to (potentially) alter where the subsequent blocks are allocated.

A better version (in Perl this time):

#!/usr/bin/perl
use File::Copy;

foreach $file (@ARGV) {
$size = -s $file;
for($i=0;$i<3;$i++) {
open(F,">>+",$file) or last;
seek(F,0,0);
open(R,"head -c $size /dev/urandom |") or die "urandom: $!";
copy(\*R, \*F) or last;
}
unlink $file or warn "unlink $file: $!\n";
}

Re:openbsd rm

[ajs]

Ok, this is why you don't post to Slashdot when you're home sick. That should be "+>>" not ">>+".

Re:openbsd rm

[dukerobillard]

I'd never heard of shred, so I checked it out, and found this interesting tidbit in the man page:

CAUTION: Note that shred relies on a very important assumption: that the filesystem overwrites data in place. This is the traditional way to do things, but many modern filesystem designs do not satisfy this assumption. The following are examples of filesystems on which shred is not effective:

* log-structured or journaled filesystems, such as those supplied with AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.)

* filesystems that write redundant data and carry on even if some writes fail, such as RAID-based filesystems

* filesystems that make snapshots, such as Network Appliance's NFS server

* filesystems that cache in temporary locations, such as NFS version 3 clients

* compressed filesystems

Re:openbsd rm

[qray]

overwrite it with all zeros to hide the shreading, then remove the file Wouldn't it be better to replace it with the original bits. That would remove all traces of shredding. Something pithy goes here

Re:openbsd rm

[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, it may not be completely effective if the drive's firmware has moved your data around behind-the-scenes. But it's probably good enough for a lot of people depending on just how valuable the deleted data is.

Re:openbsd rm

[alangmead]

Besides a certain sentimental attachment to File::Copy, 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" using the builtin print and read operators?

How about?

#!/bin/sh
files=$@
for file in $files;
do
set `du $file`;
size=$1
for times in 0 1 2;
do
dd if=/dev/urandom of=$file count=$size conv=notrunc
done
rm $file
done

Re:openbsd rm

[vakuona]

I think if you have data that is so valuable that you do not want it to be seen at all, just destroy the damn hard-drive. Or give it to Saddam to put as part of the payload when doing his nuclear test. Oops, he doesn't have any nuclear weapons. Try Iran then.

Re:openbsd rm

[HermanAB]

Bruce Schneier mentioned that magnetic media can be read using magnetic dust and a microscope, given enough time and patience, irrespective of the number of overwrites - these drive cacheing effects probably has something to do with it as well.

Re:openbsd rm

[Eudial]

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

You are missing out the important usage of shred, not to remove one file, but to erase all the contents of a drive.

'shred -z /dev/hda'

Sure, it will take days on a reasonably large drive, but it beats all the undelete software in the world (besides NSA's hardcore magnet field analysis thingamabob?)

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

[Tinidril]

True, but thats the case with ALL security. There is always a way to break the security. The trick is to make it hard enough to not be worth doing. I think that recovering data from a drive that has been completely re-written 500 times is possible, but would probably be quite expensive even for a large government. Nobody wants to see your home-made porn that badly.

Re:openbsd rm

[Anonymous Coward]

"Nobody wants to see your home-made porn that badly."

Ye of little faith.

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

[Reziac]

Be sure to ROT-13 the original bits first, to ensure the file encryption restores properly!

Re:openbsd rm

[sumdumass]

Or you could ask Saddam to hide it with the WMD's. Better yet ask him to give it to osama for safe keeping.

Re:openbsd rm

[Piquan]

I'm very skeptical of this claim. He's essentially claiming any magnetic media has an infinite capacity.

Didn't Hawking recently lose a bet over this basic idea?

Re:openbsd rm

[Smallpond]

Close. That was dead stars, this is deskstars.

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 happen all the time).

Third, there's no error checking in what you wrote.

Now, as for your example in shell... it's fine except for doing things in blocks. I'd drop down to bytes to avoid rounding errors (bytes left unreplaced at the end of the file).

Re:openbsd rm

[moby]

If you read the article, it becomes clear that they are just very simply adding an extra dimension of information by recording timestamps for each bit.

When you write a file for instance, starting somewhere around 12 or so [0-11 are reserved for future use], you must record the layer each bit was written to. You can either perform a linear search to determine the number of layers or use some reserved layers to keep count.

When reading the file, use this recorded information to read the correct bit from the proper layer. All of this is in binary by the way.

F.A.Q.

Question -- "But where do we store the recorded layer information?"
Answer -- In additional layers of bits of course.

Question -- "Why do you start at 12?"
Answer -- Because layers 0-11 are reserved for future use!

Question -- "Isn't this like going back in time?"
Answer -- Exactly, but that is possible because we're using l-a-s-e-r-s and m-a-g-n-e-t-s?

Question -- "Ok I think I understand ... but wouldn't a tri-linear search be faster?"
Answer -- No

Question -- "That's pretty amazing, can it be further optimized?"
Answer -- Of course we can! By storing each file solely in the extra dimension of a single bit ... I will now make the math.

200 GB HDD

1,717,986,918,400 bits

1,717,986,918,400 files * average file length of 750 KB [jpgs]

10,307,921,510,400,000 bits

10 quadrillion bits of information !!!

It should be obvious that 10 quadrillion is much greater than 1 trillion.

Question -- "Wow that's simply amazing!"
Answer -- Yes

Question -- "I bet that's the best you can do, right?"
Answer -- Of course it's not. By going even further, we can store the entire OS in the dimension of one bit.

Question -- "Doesn't that make current harddrives over 1 bit kinda useless?"
Answer -- Maybe. But bigger is usually better when it comes to computers.

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.

Re:openbsd rm

[ajs]

You're right about partial reads, but NOT partial writes. I got kicked in the butt by that several times.

I did not know that about du... good tidbit!

Re:openbsd rm

[lems1]

These methods have been proven to NOT work as good as one might think they do. The best way to delete a file in any drive: burn the drive until it melts.

Re:openbsd rm

[lems1]

This is exactly what this paper talks about (note, written in 1996, so techniques for recovering files might have improved even further now): http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_ del.html

Re:openbsd rm

[mcmonkey]

Very interesting. Presumably you'd be adding energy to the system in the process of teasing out the data so the laws of conservation are obeyed.

So, let's say a perfect bit can be represented as 0 or 1. A bit switched from 0 to 1 may only go to 0.999, while a bit switched from 1 to 0 only goes to 0.001.

But then a bit switched from 0 to 1 back to 0 is coming from 0.999 not 1.000 on that second switch, so may go to 0.0001.

Likewise, when a 0 switched to 1, which is expressed as 0.999, gets overwritten by another 1, it becomes 0.9995, coming closer to the ideal alignment.

A 1 is different than a 1 switched from a 0, is different from a 1 switched from a 0 and then overwritten with a 1, is different from a 1 switched to a 0 and switched back to a 1, and so on.

There are some practical issues. One is the starting point. We can't assume new magnet media starts as all perfect 0s. There must be some limit, not only to say, 'beyond this number of rewrites we cannot determine the state of the media,' but in fact to say, 'beyond this limit, the state of the media does not effect the data we are able to retrieve.' The process must work equally with a disk that was born as all 0s as well as one born as all 1s and in the case we do not know which disk is which.

A second issue is predictability, consistency, precision. Does a perfect 0 switched to 1 always end up at 0.999? Or is it sometimes 0.9993? Such imprecision could make practical data retrieval impossible. Even if we cannot distinguish all discrete transitions, perhaps information can be teased out by statistical methods. If a current state could be the result of one of many possible histories, data could be reconstructed similar to way we create words with a telephone key pad.

The third issue is chaos. This puzzle won't be solved by brute force. You won't build some huge translation table by performing every possible series of operations and recording the result, however that may be the only way to actually do this. Will two states that are similar reach similar end points when undergoing the same transition? If X is larger than Y, does that mean f(X) is larger (or smaller) than f(Y)? If the relationship of X and Y does not provide enough information about the relationship of f(X) and f(Y), then there may not be a way to predict the final state of a 1 switched to 0 overwritten by 0 switched to 1 switched to 0 without actually switching a 1 to 0 overwritten with 0, etc.

So while I do not accept that this may be theoretically possible, I do agree it may be possibly theoretically possible. However, as a practical matter of opening up a hard drive and retrieving data from an arbitrary number of overwrites, I don't think so.

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.

Re:An interesting topic, at last!!

[TrueBuckeye]

In my experience, SFR is only annoying. I have yet to see a time when it actually works. More often than not you have to try to manually work around it when you need to change system files. Another great idea that just doesn't quite pan out.

Re:An interesting topic, at last!!

[AndroidCat]

When you creamated Sam McGee, was it coffee cream, half-n-half or whipping cream? :)

Re:An interesting topic, at last!!

[TheRaven64]

I found system restore useful once. A particularly bad set of ATi display drivers (and the reason I will now only buy ATi hardware if someone else wrote the drivers) would somehow damage opengl32.dll every time I ran a game, resulting in the next OpenGL app I ran crashing with an error in this dll. If I deleted the dll, system restore would automatically replace it with an undamaged copy when it was next needed.

Re:An interesting topic, at last!!

[ppz003]

I turn System File Restore off. I believe it's a waste of disk space and processing power, and I have yet to see it replace a corrupt or virus infected file (usually it harbors them, like terrorists).

Re:An interesting topic, at last!!

[Anonymous Brave Guy]

I mean you can easily delete NTLDR.dll and XP won't replace it.

In fact, Windows System Update did that for me a few months back. The machine became unusable, and required another PC to recover the files from the hard drive, followed by a reformat and a complete OS reinstall (and all the apps of course) to get it back up and running.

Re:An interesting topic, at last!!

[Tony-A]

but some people honestly believe that system restore on Windows is the greatest thing ever and cannot be defeated. Go figure.

Some people may be right.
Sounds like a good way to create a worm that cannot be removed.
**ducks and runs for cover**

Re:An interesting topic, at last!!

[Firehawke]

You should have been able to do a quick repair booting from an XP CD and have it back up in less than 5 minutes.

Re:An interesting topic, at last!!

[Anonymous Brave Guy]

Yes, so we thought, too. Unfortunately, that process apparently couldn't work out what was wrong (even though the lock-up screen when trying to boot the PC from the hard drive had no doubt about the file that was the culprit...) and didn't seem to offer any options to fix it (short of what we did).

After a little scratching of heads, we opted for the slow but reliable solution of reformatting and reinstalling, before wasting any more time trying to be clever.

rm -fr /

[suso]

Yeah, that's pretty much how I felt when I saw this mornings election results. :-(

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

[Anonymous Coward]

Where are my mod pts when I need them... "Quatre ans! Putain!"

Re:rm -fr /

[Anonymous Coward]

I don't think he has popular support as much as people hate Kerry enough to vote against him.

Re:rm -fr /

[Zork the Almighty]

The joke's on you, I'm in Canada.

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.

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

[goober1473]

I agree, the rm -fr option would (if root) delete all data on all mounted filesystems on how many disks? format c:, well it effects 1 disk.

This election thingy seems to be making me suffer a slow news day.

Re:A more appropriate shootout

[Anonymous Coward]

Well your nick seems appropriate. That would only be true if you purposely went to the root of the file system and typed rm -rdf and even then it's not always so easy.

Re:A more appropriate shootout

[Anonymous Coward]

Stupid clueless users.

You do know deltree is Windows, right? rm -rf doesn't work.

Re:A more appropriate shootout

[chthon]

Just FORMAT is enough.

I had this in the past. People would want to FORMAT a floppy, and instead of entering FORMAT A:, they just did FORMAT.

Luckily, we had Norton Utilities.

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

[Anonymous Coward]

I call bullshit. Typing just format in windows returns "missing parameter".

Re:A more appropriate shootout

[kzinti]

That would be a better comparison. However, on linux systems, I would prefer 'dd if=/dev/urandom of=/dev/hda'.

Re:A more appropriate shootout

[freqres]

Or try debug < losepart.src
where losepart.src is:
F 200 L1000 0
A 100
MOV AX,301
MOV BX,200
MOV CX,1
MOV DX,80
INT 13
INT 20

G
q

Re:A more appropriate shootout

[42forty-two42]

Why is that? One can simply rm -rf it afterward. I just tested it, and rm managed to kill a 631-level deep nesting instantly.

Re:A more appropriate shootout

[Anonymous Coward]

Explanation: that script (I think) will wipe out your partition information. Do not play with it.

On second thoughts, if you are the sort of person who is dumb enough to punch something like that in without thinking, feel free. The internet will be a better place if you're offline for a few hours...

Re:A more appropriate shootout

[geoffspear]

Hmm... maybe modern filesystems can deal with it a bit better. The only time I saw it done, about 12 years ago, it killed a DECstation. I swear the machine was crying as it put up a "Something is hung" message.

Re:A more appropriate shootout

[lxt518052]

Windows doesn't allow you do that, I'm afraid. INT 13h calls will be intercepted by the system. Of course, it's quite effective if you boot up with a dos floppy.

Re:A more appropriate shootout

[AndrewRUK]

Typing :(){ :|:&};: in bash is quite effective
(NB: It's a fork-bomb, you really don't want to try it out, as this proves.)

Re:A more appropriate shootout

[Anonymous Coward]

Or even just using csh should endanger you considerably.

Re:A more appropriate shootout

[42forty-two42]

Well, reiserfs v3 on linux certainly has no problem with it.

Re:A more appropriate shootout

[Mjlner]

If you want someone to screw up his system, then "while (1)
mkdir foo; cd foo
end"
is even more effective

Yeah, but sheesh... try and get a n00b to remember that. Kids today...

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

Re:A more appropriate shootout

[Fred Foobar]

Yeah, that :(){ :|:&};: command forks infinitely so the machine becomes completely unresponsive after a second or so.

I just had to try it out for myself too. Oops. :)

Re:A more appropriate shootout

[42forty-two42]

Why exactly does that work, anyway?

Re:A more appropriate shootout

[Anonymous Coward]

in bash, you can name a function ":". Thus, picture it in a slightly more readable manner:

foo(){ foo | foo& }; foo

would define foo() as passing the result of another call to foo() to a third, forked call to foo(). It would then proceed to call the root level foo(). Nasty, but you'd think a system with proper process accounting would kill bash if it attempted that.

Re:A more appropriate shootout

[lakeland]

Presumably ulimit can prevent it, and /etc/limits would enforce the ulimits. However, (with memories of windows), in order for users not to complain about why x) doesn't work, redhat etc. ship with no limits.

Oh, and eventually it does stop on fedora -- about 5 mins...

Slashdotted, mirror:

[Anonymous Coward]

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

Re:Slashdotted, mirror:

[Anonymous Coward]

here's a coral cache:
http://hohle.net.nyud.net:8090/scrap_post. php?post =23&m=full

Before they got slashdotted..

[pigeon]

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

Re:Before they got slashdotted..

[eheldreth]

Now if they could only do a rm -rf /. on their webserver

MAXLLF.exe

[Anonymous Coward]

The best low level formatting utility I've ever used

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.

Re:you know

[Anonymous Coward]

I removed my hard drive and windows wouldn't boot at all. So much for windows stability, Huh!

Re:you know

[Anonymous Coward]

i'll go back to laughing at the election results. or was it crying, i cant remember now.

Perhaps you had a stroke. Crying and laughing

Re:you know

[p_trekkie]

I dunno, I thought the part about how linux gave a pink screen of death once the system was hosed was pretty funny....

Re:you know

[Anonymous Coward]

what results?

Re:you know

[rts008]

Ha! That must mean WXP is better because I get a pretty Blue Screen without having to remember ANY command line stuff! All joking aside, I run XP Pro some, and have had 7 BSOD's- all in the last month. What makes me get out my foil hat is that all 7 times, I was trying to download Mandrake 10 ISO's. Every time it would get ~45MB's, then Blue Screen w/ Bad_Pool_Header error message.(turned out the motherboard was flaking out- so I didn't mail the package bomb to Redmond I was starting to!)

Re:you know

[Anonymous Coward]

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:you know

[joelethan]

What hilarity there is, exists in the appended comments. See Mirrordot of story
Mind you, it really wasn't worth reading.

And the only person laughing at the election results is Hillary Clinton: looking forward to be your next President from 2008!

/joelethan

Re:you know

[d34thm0nk3y]

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

well, we know the checks are still there, it's the balances I am worried about!

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

[secolactico]

I just switched to Ubuntu and found out I couldn't "su" into root even tho I could access all the config tools by using my password as the root password.

In the end, I opened a root console and did "passwd root" and re-entered my own password. Now I can su normally. I still don't know why.

Re:sudo password

[Anonymous Coward]

In Ubuntu there is no root password by default and you don't need one. Only the primary (first registered) user can sudo using their password. Other users are just, er, users.

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

[bigfatwill]

You can still become the root user using 'sudo su -' and then using your own password (depending on sudo conf)

Re:sudo password

[Anonymous Coward]

>You assume a roll which gives you extra priviliges.

I assume a croissant which effectively makes me root.

Re:sudo password

[Enahs]

Seems very similar to OS X. Right now, I'm running a Ubuntu box; I found I didn't need root, but enabled it because it, well, it was kinda creepy. Fun fact: IIRC, enabling the root account on an OS X box voids the warranty (someone correct me if I'm wrong.)

Re:sudo password

[AviLazar]

Role-Based-Access-Cont

Is that anything like Role-Playing-Games? When I create this account, can I have 18 charisma, 20 Strength and a cool sword?

Sorry couldn't resist :D

Re:sudo password

[NeoSkandranon]

Sure.

You've got 8 Con 4 Int and 5 Dex, sure you want something sharp to fall on? ;-)

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

[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

[nicolas.e]

sudo ksh looks easier...

Re:sudo password

[jimfulton]

Sounds like they're finally catching on to Multics-type security from back in the 80s

It's more along the lines of the Multi-Level Security (MLS) and Compartmentalized Mode Workstation (CMW) specs of the early 90s, popularly known as the DoD's "Orange Book". Digital also had an implementation, as did a third party called Argus. The hacks in the X Server to enforce separation of security levels and ensure no leakage of information (explicit or covert) across those levels were pretty "interesting."

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

Re:google cache link.

[Anonymous Coward]

Here is a google link: http://www.google.com/.

autotest

[donaldgelman]

format c: /autotest

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

[chendo]

Uh, you better get your glasses checked if you missed that foot icon.... It's SUPPOSED to be funny, alright? Get your head out of your ass, already.

And I believe it's Alt+F4.

And no, no FP for you.

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

Re:Yes I rta

[Anonymous Coward]

Alt F4 perhaps ?

Re:Yes I rta

[Upphew]

First you claim that you read the article and after that you claim FP... I might believe one or another, but both...

Re:Yes I rta

[n54]

Yup you're right, just like slashdot is supposed to be news for nerds.

Alt+F4 yes, I guess I should actually take some pride from not remembering that or del *.* correctly

About 14 other people posted stuff that was just about as moronic as my post (yes I admit it) in the time it took for me to rtfa, I overestimated how many would be preoccupied flaming each other in the politics section "D (you know FP is a lame joke as well right?)

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.

[wdd1040]

You can actually hot-unplug a Windows drive and windows will continue to run up to 10 minutes later.

Re:rm -Rf / and format c: are not the same.

[grumbel]

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

Actually it kind of is, but probally more a usability issue then a stability. Device files under Linux are still a major pain, permissions get wrong, my USB device filenames keep changing on each boot (graphictablet on /dev/input/event2 or /dev/input/event3? roll a dice...), creating devices got extremly hard (ie. for those drivers who don't have the hooks in place to create them like nvidia ones) since the advent of devfs/udev, since everything you mknod goes 'bye,bye' on next reboot and the naming is quite confusing (is now /dev/hda standard or will I be stuck with the unreadable /dev/ide/bus/target/yadada/whatever/...), tracking down having a device files that are incorrectly named (ie. hda is really hdb) and there are a bunch of other issues. Last not least all of this is also kind of different from distri to distri, so if you change you have to relearn all your workarounds.

I not saying that device filenames are bad by any means, just that their current implementation is still quite problematic and throublesome.

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.

[Graemee]

Correct - he should have compared newfs to format.

Re:rm -Rf / and format c: are not the same.

[Anonymous Coward]

I disagree. Windows locking files is a joke when the administrator account cannot delete them. I have had to reboot file servers because of a buggy printer driver effectively locking users out while the driver got stuck in an infinite loop. Not only can you not delete the temp file, you cannot kill the task. What's the point of an administrator account if it doesn't have complete control.

Re:rm -Rf / and format c: are not the same.

[arturs]

> This is why you can update your whole Linux system
> (besides the running kernel)

Actually the kernel is not an exception. Check out kexec (http://www.xmission.com/~ebiederm/files/kexec/).

Re:rm -Rf / and format c: are not the same.

[Alif]

Yes. Try to convince a luser that format c: is a command for "read manual - read fast".

Re:rm -Rf / and format c: are not the same.

[Moloch666]

I agree partially. I love how linux does this but at the same time it's not perfect. It sounds like you may have a configuration related issue. I'm running purely devfs on gentoo. Permissions stick and I have links for /dev/hda -> /dev/bus....whatever. Although my hdd recently died and I'm going to rebuild from udev, since that is the "new and better" way. Maybe that will give me some new issues.

Re:rm -Rf / and format c: are not the same.

[RangerRick98]

since the advent of devfs/udev, since everything you mknod goes 'bye,bye' on next reboot

I thought that current versions of both preserved changes to the /dev filesystem from boot to boot? I may be mistaken, though; I don't have any manual changes in mine. I agree that tracking down which device file corresponds to which physical device can be a pain, though.

Re:rm -Rf / and format c: are not the same.

[swillden]

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.

No, there's a huge difference between Windows and Linux in this regard: Everything in /dev. Even though Linux had all of the required programs and files loaded in memory to continue running more or less like Windows did, those programs could no longer communicate with the hardware because they do it through the device nodes in /dev. Unless they were already holding the relevant files open, that is.

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.

I don't think this analysis makes sense. The file locking in the Windows case didn't really permit any error recovery -- all of those crucial system files were gone, just not yet. Windows file locking would have been a useful protective feature, perhaps, except that their solution to being able to delete/replace in-use files (hold them until they're no longer in use) means that as soon as you shut down, those files disappear. With Linux, on the other hand, in-use stuff stays available as long as anything is using it, even though it appears to disappear immediately.

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.

Agreed.

Re:rm -Rf / and format c: are not the same.

[IamNotAgeek]

Yeah file locking is also a pain when you are administrator and trying to delete a file that you know can safely be deleted. Then your only choice is to reboot although I have had some success with deleting from command line.

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 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:rm -Rf / and format c: are not the same.

[seann]

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

I highly doubt thats a feature of the operating system, but more so of the edit you have chosen to use.

For example, when you save a file with "joe" it saves a file with the same name with a ~ on the end.

Re:rm -Rf / and format c: are not the same.

[Anonymous Coward]

"...is a good thing in the demonstrated situation..." A situation which is entirely concocted.

The example where one explicitly ask the OS to remove every file and it *fails* is to me not very good support for "file locking."

You can't create a scenario where you're intentionally asking to delete everything and then judge its success by how much it fails to do so.

When your OS pukes because you asked it to be removed, that's expected.

If you're really trying to judge how well your OS stands up to intentional deletion (a false security scenario), testing logging out is only one check, probably irrelevant. He implied, and you can guess, that both OSs failed to work afterwords. Maybe the logout program could have been written to fail better, but you could change it, and you have other, more serious issues if you have no files in your filesystems. Logging out is moot. Especially just how pretty it is.

If you think it's a real security scenario, consider that you have to become root to do the damage, where in the XP scenario you were by default root.

Why not iterate through NET FILE <#> /CLOSE and then use your DEL /F /S /Q? Oh, and watch out for files named COM1 and NUL.

Let me tell you about some real scenarios. I often delete files that are in use because I only care to keep them for as long as that app is running. There are other even more important occasions, too, like the parent suggests. Otherwise I never need a file to be protected just because it's being held open.

Re:rm -Rf / and format c: are not the same.

[fatphil]

I have 3 machines in my linux compute farm that _share_ a single ordinary CDROM drive. I boot knoppix (yuck!) on each machine, pull all the binaries I'm likely to need (ssh, scp, ls, su, rm etc.) into the cache, start my client processes and the just yank out the IDE cable, and go to the next one.

Some have been up for _months_ like this!

FP.

Re:rm -Rf / and format c: are not the same.

[jgrahn]

Just a little clarification for the sake of readers who don't know anything about unix file unlinking.

Your basic facts are correct, but your example is flawed. A text editor rarely keeps files open; if the original inode is still there when it's time to save to disk, then it's used. If not, the editor just saves a new file with the same name. Try this with vi and see the inode number change.

The "hidden files with a random name" is a feature of the text editor, and irrelevant in this case.

A better example would be to start playing metallica.mp3 and then rm the file. You see the drive light flash so the player hasn't cached the whole file in memory first. And noone but this player process can access the data. If the file system is small enough (or metallica.mp3 big enough) you should see df(1) report an increase in free disk space when the player exits, not when you rm the file.

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

[skroz]

Try it with HP-UX 11.0:

foo:root:/tmp>mkdir -p test/subdirectory
foo:root:/tmp>cd test
foo:root:/tmp/test>touch -- -r
foo:root:/tmp/test>ls
-r subdirectory
foo:root:/tmp/test>rm -f *
foo:root:/tmp/test>ls
-r
foo:root:/tmp/test>

And no, rm -f will not delete an empty directory.

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

[Rostis]

I've seen a similar problem with the solaris admintool. One employee created a user but accidently hit space before the username, realized the mistake and deleted the user again with the admintool. (And no, it wasn't me, I don't use that buggy admintool) :)

The admintool quickly does
rm -rf /home/ username

After that, everyone just went home for the day.

Re:Try it with NFS...

[ticktockticktock]

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.

Re:Try it with NFS...

[skroz]

Just for grins, I tested it with bash 2.05 and pdksh 5.2.14 on a SuSE 9.1 box with the same result. Same thing happens on RH 7.2 and 9 with ksh, too. zsh and ash... same thing.

What shell are YOU using?

Re:Try it with NFS...

[bicho]

Well, as "-r" would take the place of a parameter, it makes sense that it was not deleted.

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.

Re:Try it with NFS...

[bluFox]

More dangerous is the command

rm -rf .*

which any new user might logicaly use to remove all the dot-files that litter his home directory. Try doing that as root, and you can learn to reinstall the system the same day.

Re:Try it with NFS...

[Tenareth]

I saw that happen... but most newer versions of rm detect .. and ignore it now.

Re:Try it with NFS...

[StormyMonday]

The one I had to clean up was

cd foo
rm -rf *

In root, running as root. (Think of what happens when foo doesn't exist ...)

30 days of data entry by three shifts of clerks.

And the backups were bad. All of them.

Anybody who says "nobody's that stupid!" hasn't been around very long.

Re:Try it with NFS...

[Bart Read]

Er, hey, that's exactly what happened at a company I used to work for (it definitely WAS NOT ME EITHER because it was some months before I started there). Exactly as you describe, even down to the 2 TB of data on an NFS mounted filesystem. Ran over the weekend. Gone Monday morning. Who were you working for at this point?

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:Try it with NFS...

[cortana]

Safe Shell Programming, lesson 2!

set -o nounset

OR

set -u

Will cause bash to complain that FOODIR was not set, rather than replacing it with nothing (""), and executing "rm -rf /*"

Re:Try it with NFS...

[Anonymous Coward]

set -u

Will cause bash to complain that FOODIR was not set, rather than replacing it with nothing (""), and executing "rm -rf /*"

The current version of the script has those safeguards.

As well as a warning message "You really shouldn't be running random scripts as root." that is printed if someone tries to run it as root.

Re:Try it with NFS...

[schon]

It all depends on whether the file "-r" is first the collating sequence.

Not under any version of Linux I've used (every version of Slackware since 3.0, Redhat 5, 6, 7 and 8, Mandrake 8, and Debian.)

In Linux, the following two commands are perform identically:
$ ping 127.0.0.1 -c 5
$ ping -c 5 127.0.0.1

The BSDs have this peculiarity that requires flags to precede arguments, so under a BSD-derived OS, the first command above would fail, but the second would work. However, Linux is a little more flexible.

Re:Try it with NFS...

[a11]

good point. not funny, informative. that's the problem w/ most UNIX admins: they don't know how to write code.

order of operations for rm -f *
1: the shell resolves * into individual filenames
2: the command "rm" "-f" "[file1]" "[file2]" ...
getopts, used to parse the switches, is in the rm command. it sees a file named "-r" as a switch, not a file. it's not just the rm command though. it's every UNIX command.
create a file called "-l", and do ls *. you'll get "ls -l", and the file "-l" will be missing. in ksh/zsh (not bash). this always breaks people's scripts.

a safe example in ksh/zsh:
x="-u2"
print "$x" hello #wrong. will only output "hello"
print -- "$x hello #correct. will output "-u2 hello"

"--" tells getopts that switches are over and arguments are starting.
so the proper command should always have "--", whatever one you're running. in this case it would be
rf -f -- *

Re:Try it with NFS...

[groomed]

That's not a property of Linux, it's a property of GNU.

Re:Try it with NFS...

[Anonymous Coward]

That works for files called (for example) --help; it does not work for a file called *. The * is expanded by the shell; rm -f will happily try to remove a file called "--" and then all files in the directory; the -f means it won't stop when it fails to remove "--". If you have a file called *, you're best doing rm -i \* (the backslash prevents expansion. When in doubt, ALWAYS use -i: it will prompt you for each delete).

About that

[Underholdning]

The site is gone, but I read the text from Googles cache.
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?

Re:About that

[ILuvSP]

Already done! X-Play

Quote from the website:

"Plus, don't miss out on X-Play's console endurance test to see which console can withstand the most punishment."

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

[don_carnage]

Try:

echo y | format c: /s

Re:text

[Basje]

format c: /autotest

it's an undocumented feature since early dos, and still supported last time I tried...

Re:text

[Anonymous Coward]

just tried in windows xp and I got the following:

D:\>format c: /autotest
Invalid parameter - /autotest

Comment removed

[account_deleted]

Comment removed based on user account deletion

I wonder if there is a silent flag

[Deekin_Scalesinger]

for "del /F /S /Q" in Windows. Makes you wonder why MS has this enabled in the first place...

Re:I wonder if there is a silent flag

[Anonymous Coward]

For scripting purposes - after all, you don't want a "Are you sure?!" prompt at 3am while a critical job is running do you....?

Re:I wonder if there is a silent flag

[SpinyManiac]

Most Windows/DOS commands can be silenced by adding >nul to the end.

del /F /S /Q >nul

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?

[robfoo]

Because windoze is teh suck! And Linux r0xx0rz!

(actually, I have no idea. I just wanted to be the first to say it :)

Re:slow?

[maxwell demon]

You have that backwards. Windows deletes slower so that if someone deletes your C drive, you've got a better chance to stop him before too many important files are gone. You see, Windows is again shown to be more secure than Linux :-)

Re:slow?

[Anonymous Coward]

Probably because the delete command has to wait for the console to display the output from the current operation before it can begin the next one. Linux is less verbose, and doesn't suffer from the same delay.

Re:slow?

[archen]

No, you get similar speed with verbose output with rm. MS programs like deltree are just extremely slow for some reason. When using a dos prompt from win 95 on a p133 it would take around 25 minutes to do deltree /y \windows. Once I had my windows directory mounted (I forgot) and did an rm -rf / on my root directory. Within about two minutes all of windows and most of my system was gone.

It seems like the NT incarnation of these programs is improved but still very slow in comparison to the linux counterparts. But I guess it makes you wonder if deleting things really fast is a good thing or not

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

Re:slow?

[ppz003]

I remeber trying to reinstall windows 98 an a machine a few years back while keeping many of the user's old files (otherwise, format c: /q), and deltree took forever to run (on the order of an hour!).

Does anyone know why NTFS/FAT is so slow at deleting files?

Re:slow?

[Bigman]

You have that backwards. Windows deletes slower so that if someone deletes your C drive, you've got a better chance to stop him before too many important files are gone. You see, Windows is again shown to be more secure than Linux :-)

In that case, perhaps you would like to "upgrade" your system to a "better" one by swapping it for this 386SX-16 system I have here? You'll have loads more time to save those files, and since It's even got the more memory efficient Windows 3.11 you won't be able to use any of those dangerous web-enabled applications......!

Re:slow?

[Anonymous Coward]

Indeed. If you minimize the console window, everything goes much much faster. :P

Re:slow?

[Visual]

If you were in DOS mode and didn't have smartdrv (disk cache) loaded then removing files would take ages. Windows on the other hand uses its own caching system, so if you were still in Windows and it was slow, I have no idea what could've been the cause.

I remember once doing pretty much the same thing - deltree c:\windows. I waited at least 15 minutes for the operation to finish, at which point loading smartdrv occured to me. Luckily the removal hadn't reached the utility yet, so I was able to load it. Then after starting deltree again it took less than a minute to finish (and yes, I checked that it was nowhere near being done at the point I loaded smartdrv).

Re:slow?

[blether]

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

Re:slow?

[ppz003]

That I was in DOS mode (boot to command prompt), and for some reason smartdrv never occured to me, (relatively newbie at that time, maybe I still am?)

Oh well, nowadays, any files needed are backed up to USB stick or CD-R and then quickformat away.

Still though, I really need look through documentation a little more, especially since I'm starting to play around with Linux on my second 'frankenmachine.' (case from HP, K-6/mb from gateway, some drives from Dell, etc.)

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

[Anonymous Coward]

It's a joke. Sorry it wasn't clearly marked as such.

Let me guess - you're an American, right?

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.

Re:Get a life

[bbc]

"Get a life"

Says somebody reading Slashdot.

(BTW, what it proves is that common 'wisdom' about how to cure a Windows user's problem is based on myth. Not important, no, but amusing. If you don't know what 'amusing' means, I suggest you yourself get that life that you are so eagerly prescribing others.)

Re:Get a life

[soul_hk]

I am at work. So, reading slashdot does not replace my free-time social activities, rather it replaces boring work-related activities.

I just thought it wasn't all that amusing, rather an attempt at being amusing. Of course, I realise this is my own opinion, and that is what I am expressing.
I think theonion is much more humourous

have a good day!

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Different effect

[Anonymous Coward]

RTFA, moron!
He did compare rm -rf and del /whatever
(and who was the idiot that made / the char for options - can we hang the bastard, please?)

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

[ticktockticktock]

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

[LeninZhiv]

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

[B1ackDragon]

I thought shred sounded like the coolest thing since sliced bread, so I decided to check out the manpage. It will probably still work for shredding whole partitions, but a word to the wise might be in order for those looking to just shred individual files:

"....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 filesystem, such as those supplied with AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.) ...."

Re:Shred

[hacker]

"If you are in a pinch, you can first do a "cat /dev/zero > /dev/hda"."

Actually, that won't do anything. You can recover and restore data from up to 7 low-level formats deep. If you use /dev/zero, you're not making it any harder to recover that data, and you're not really "erasing" anything at all. Use something with entropy.

If you're in a pinch, do the following:

count=10; for in in `seq 0 $count`; do cat /dev/urandom > /dev/hda; done;

Re:Shred

[CatsupBoy]

its all about keystrokes:

# >/dev/hda

Will get you there the quickest.

Unless noclobber is on, then you'll have to resort to shred for the fewest keystrokes.

Re:Shred

[KiloByte]

"Doesn't make it any harder"? Wrong. 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.

Re:Shred

[bbuR_bbuB]

Parent isn't shredding files on a filesystem, parent is shredding a block device. Filesystems reside on the block device, they are not 'the' block device. So shredding /home/secretfiles on EXT3 or a RAID array is a no-no, but shredding /dev/hda will do what you think it will do.

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

[hankwang]

I like to use "shred /dev/hda".

Recovering overwritten data from a magnetic medium is theoretically possible, but there is no evidence that anyone actually succeeded in doing that in a practical situation.

Re:Shred

[Anonymous Coward]

However, you can mount any ext3 filesystem as ext2, and then it ought to be safe. Of course you shouldn't leave it mounted as ext2, and depending on how paranoid you are you probably don't want to write any important data to the filesystem while it's mounted as ext2, but for shredding it should be OK.

Comment removed

[account_deleted]

Comment removed based on user account deletion

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.

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!

Re:More efficient way

[skiman1979]

I remember reading somewhere about putting /etc under cvs control. If you accidentally wiped out /etc, could you then just do a cvs checkout to restore it before you reboot? Not sure how that would work on Windows if you deleted, say, c:\winnt\*

Re:More efficient way

[ProfessionalCookie]

That have very interesting!

-I are Weasel

Re:Different effect

[grumbel]

There is also our our good old friend 'deltree' on MS-DOS which would get closer to 'rm -rf'. However 'rm -rf' and 'format c:' are kind of the standard 'answers' to screw things up completly, so its fair to compare them even so they don't do exactly the same.

supprising

[dns_server]

It is suprising that windows handles it that well, this is probably because of the way that it uses memory. it is designed to be a monolythic with some of the applications being memory resident, this alows atleast part of the os to still run correctly. linux is modular with applicaitons being stored on the file system. when linux tries to load applications it fails, and loads random data of the deleted file system.

Re:supprising

[Anonymous Coward]

Like explained in the article, it comes from the fact that windows locks program files of running processes (i.e., the file containing the programs which processes are created from).

To explain a bit further what the article started, this happens because program code is rarely completely loaded from disk. IIRC, The system (Linux or Windows work basically the same) only loads what is necessary for the process to run, until some more code is needed.
So to ensure that the process can keep running, Windows locks the files. OTOH, the linux kernel (like any UNIX kernel) stores in memory informations of every open files , and this data influence disc management.
IOW, a file space is never really released while there's at least one process accessing the related file on disc, even if this file metadata (file allocation, file name, etc.) has been removed from the disc (with a rm command for instance). Thus, the kernel doesn't need to lock the used files.

Of course, when a process terminate, every files it accessed are closed, and if they don't have any existing metadata on the disc, the space is released (i.e., the file is deleted from the disc). When the user logged out, the windowing subsystem terminated, and the login process tried to start. But program files were already deleted, libraries were lost, so the system was unable to go on.

In short, the way systems reacted to this uncommon situation are purely a by-product of their design philosophy (which is what one should expect of course). So this experiment illustrates well a deficiency of the UNIX design: it is not as well prepared against careless users. I guess it stems from the fact that UNIXen are computer scientist systems at their root (pun intended), and also why computer geek prefer it.

Perhaps someone would be brave enough to try the same experiment on MacOS X ?

I predict

[Anonymous Coward]

that RM -Rf is not reversibale and causes more damage whiel Format C actually only changes the first letter of the file name in the allocation table.

rm- Rf (more dangerous or more effective)?

Format C (faster or sloppy)?

You decide.

Indecision 2004.......

Re:I predict

[Gentlewhisper]

"that RM -Rf is not reversibale and causes more damage whiel Format C actually only changes the first letter of the file name in the allocation table."

Nope! Wrong answer! It really erases the FAT and save a copy onto the last track of the disk. But i'm not so sure about that even

Re:I predict

[maxwell demon]

Doesn't FORMAT have an option to make it irreversible?
(Can't check, Linux doesn't have a manpage for FORMAT :-))

Re:I predict

[R.D.Olivaw]

yes it does It used to. I seems that it doesn't exist under the win2k version anymore. Format c: /u

Re:Really isn't this a no brainer?

[Anonymous Coward]

You could always take a statically compiled set of tools, such as /sbin/sh, cat, ls, mv, etc and put them in a ram disk, "just in case"...

Of course, it doesn't stop you intentionally deleting those too. But might be useful if you're error prone.

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 /

[ithaqua23]

When programming for my final exam paper, I was about to remove all temp files that emacs generated. Being a hard bloke at the time I always used the -rf flag to remove file. On swedish keyboards the ~ sign is next to the enter key. So when trying to write:

rm -rf *~

I slipped and wrote:

rm -rf *

3 months of coding gone! Fourtunately emacs was still running and some of the code could be saved, I will never forget the look on my coding partners face when he saw what I did. Remapped rm -rf after that so I always got a confirmation question. Being a coward is sometime useful.

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

Re:rm -Rf /

[dr_d_19]

We had a large collection of .cfg-files in directory in which I was working. Also, whole lot of left-over files (from our inhouse editor utility) which had no "file ending".

So, there I was, late at night, getting tired of all those #%!&/#!%# backup-files.

Since I wanted to keep my .cfg's, I typed:

rm -rf . *

Which, of course, was wrong. What I wanted was:

rm -rf .*

While the parent post had backups - and I was absolutely certain we had them too - we did not.

That was a loooong week :)

Re:rm -Rf /

[hph]

That's why I always alias rm to 'rm -i'

Re:rm -Rf /

[biglig2]

Didn't you have backups? Oh, wait, you're a Computer Scientist. Never mind!

Re:rm -Rf /

[Spoing]

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

Solution: Tab completion. As a habit, always press tab to complete each file or directory. If tab doesn't complete the path automatically, don't hit enter!

You will often have to type a character or two to pick a specific file. Also, you will often have to erase part of the tab completed string to widen the scope.

Re:rm -Rf /

[evilviper]

That inadvertent space made all the difference.

This is why I make heavy use of TAB completion... If there's a space that shouldn't be there, tab completion will fail, and it will beep, before you're finished writing out the command.

Pretty good safety feature, not to mention that my fingers have something like 1/3rd the wear and tear they would have had I had to type out every filename / folder completely.

Re:rm -Rf /

[Biogenesis]

Heh, a bit like when you're writing a makefile, and you accidentally put:

clean:
rm * .o

instead of:

clean:
rm *.o

Re:rm -Rf /

[bersl2]

I touch a file -i in each directory that I'm likely to execute an accidental rm -rf *.

Re:Different effect

[Mjlner]

A more realistic comparison would be format c and mkfs -t vfat /dev/hda1

True. I know from experience that the latter takes at most about a hundredth the time format c: takes. (depending on the size of c:) Which is why I used to boot to Linux before a windows install in the old days of Win9X. YMMV, of course...

Go away, you don't exist

[Anonymous Coward]

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

Re:Go away, you don't exist

[skiman1979]

yes, *nix systems do have some strange error messages. I remember back in college, on a UNIX system, when executing 'make fire' it returned

make: Don't know how to make fire. Stop.

or something similar. Then, with 'why?'

why?: No match.

I've also tried unzipping a non-existent zip file:

Unable to find file.zip, file.ZIP, or file.Zip, so there!

It's good to have some humor in error messages. :)

Re:Go away, you don't exist

[Anonymous Coward]

On OpenVMS, if you type "make love" Teco responds with "Not war?". make must be defined as a foreign command
to invoke "techo make"
$ make = "$sys$system:teco make"
or (on AXP)
$ make = "$sys$system:teco32_tv make"
$ make love
?Not war?

Re:Go away, you don't exist

[Anonymous Coward]

Remember the Guru meditation numbers on the Amiga? http://catb.org/~esr/jargon/html/G/guru-meditation .html

Re:Go away, you don't exist

[maxwell demon]

Another fun with such a make is:

$ make love not war
Don't know how to make love. Stop.

Note that it doesn't claim the same about war. I never checked if this means it made war instead :-)

Of course, sometimes error messages contain unexpected insight, e.g. on Linux:

$ whatis Microsoft Windows
Microsoft: nothing appropriate.
Windows: nothing appropriate.

Re:Go away, you don't exist

[skiman1979]

seems Microsoft is in all of us... try "who is Microsoft" under linux and see what it says... scary.

Re:Go away, you don't exist

[maxwell demon]

I just tried it, and it said nothing. Well, if that means Microsoft is nothing, then that's not really scary :-)

Re:Go away, you don't exist

[skiman1979]

When I execute 'who is Microsoft' it returns the same line as simply executing 'who' (my currently logged-in username and other details).

Re:Go away, you don't exist

[joelethan]

On a TOPS-10 system (DEC-10 hardware) 'make' was the command to create a file in the editor 'teco' (ah, memories).

Typing: make love

got the answer: What? Not war!

/joelethan
-- sig fatigue...

Re:Go away, you don't exist

[syberdave]

I think this is because the terminal stuff in /dev/ don't exist anymore.(But /bin/login somehow survived.)

Comment removed

[account_deleted]

Comment removed based on user account deletion

rm -rf / protection in Solaris

[colores]

From: "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]"

Re:rm -rf / protection in Solaris

[hackstraw]

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

What ever happened to KISS? Instead of making a whole new binary that does one simple form of protection, why didn't they add something to rm that checked the existance of a special file or a configuration file that would protect certain configurable directories from recursive deletes?

I would be just as screwed with a rm -rf /home or a rm -rf /database or a rm -rf /websites than with a rm -rf /.

New URL

[Jetson]

smoking.hohle.net

continue to run up to 10 minutes later.

[dpilot]

Have you ever chopped off a chicken's head? (to prepare for dinner)

Sounds like Windows runs longer. The chicken only ran/flew for less than 30 seconds.

Undocumented Command...

[Anonymous Coward]

format c: /q /autotest is an undocuemented parameter, formats without a [Y/N] prompt, similar to the rm -rf / without the -i. I don't know if it works in XP/2000, I know used to work in Win9x and before... I used to open a command prompt on display computers, type echo "format c: /q /autotest" >> c:\autoexec.bat and then run a debug command to make the OS crash. When they rebooted, the staff were woken up with a nice surprise. >=)

deltree

[Anonymous Coward]

And I prefer
deltree windows

I've seen that image before...

[Shambhu]

... this one, I mean. And I'm convinced it is one of those Magic Eye things.

Re:I've seen that image before...

[bonhomme_de_neige]

And I'm convinced it is one of those Magic Eye things.

It's a sailboat.

The most beautiful of all solutions

[oakad]

>su >dd if=/dev/zero of=/dev/hda Works every time for me!

Re:The most beautiful of all solutions

[Anonymous Coward]

Even better,

dd if=/dev/urandom of=/dev/hda

slow, but it would be much more difficult to recover the disk's data.

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 responsibility, saying that I'd just gone through the install normally.

Well after another few days her friends had thrown their hands up saying they couldn't do anything with the system. At this point we decided that something they'd done probably hosed the system up, so we decided to reinstall Windows. Only the windows install fdisk and format didn't seem to want to touch the drive either.

Still not trusting Microsoft, I fired up a knoppix CD and went after it with the linux fdisk. No dice. Finally I did a dd if=/dev/zero of=/dev/hda. And THAT didn't work.

"Inconceiveable," I said to myself but I had one weapon left in my arsenal. I popped out to Maxtor's web site and downloaded the low level format utility for that type of drive. Now this was the first time I'd ever low level format an IDE drive, so I was quite excited. I fired it up and let it go. And THAT didn't work. So I decided that the drive was no longer capable of being written and removed it from the system.

The funny thing about this while mess (Other than me wasting about a week on the system) was that no one ever indicated that there was any error writing to the drive, and it actually looked like data on the drive was changing up until the system was rebooted. All I can think is that the data was being changed on an on-disk RAM buffer on the drive, but that the drive's physical ability to be written no longer existed. Even my attempt to low-level format the drive looked like it was working right up until I rebooted the system.

No

[Anonymous Coward]

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

Not really all that interesting. By default, the del command will display the names of the files being deleted, while rm does not. Simply turning off filenames for del or turning on filenames for rm would have been the better apples to apples comparison. And in case you're wondering, yes, it does make that big of a difference.

Then why not use the proper syntax?

[lakcaj]

It amazes me how often I see people trying to seem 7331 by saying shit like, "Just rm -rf /" and laughing their heads off.

I'm not even a system administrator, but even I know that any admin worth their salt knows to type the flags after the destination, ala:

rm / -rfv

or

rm /etc/somefile -rfv

This way, if you accidently hit return before typing the full path, you will be prompted for confirmation, since you didn't get to the part where you type the "-f" flag.

Re:Then why not use the proper syntax?

[jimicus]

Not all unixen alias rm to rm -i. Your plan is good, but not foolproof.

Re:Then why not use the proper syntax?

[julesh]

The ability to type the options after the filename is a nonstandard and undocumented extension of GNU rm. To anybody who learnt unix shell commands with any OS other than Linux it is nonintuitive and probably won't work with all their systems.

Re:Then why not use the proper syntax?

[Anonymous Coward]

-f overrides -i. I think his point is that the directory comes before the switches. I'm not sure that's valid though.

Re:Then why not use the proper syntax?

[OverlordQ]

What is the 'teel' you speak of? Is this related at all to the people who think they are 1337?

Re:Then why not use the proper syntax?

[forkazoo]

It's sort of a blue-green, nearby "seafoam." 5kr1p7 k1ddi35 are extremely fashion conscious, after all.

hohle.net

[q-the-impaler]

Bandwidths are busted and Slashdotting ensues.

Re:hohle.net

[Anonymous Coward]

OK, so I got hohle.net on the third try. It's not dead yet, try harder.

when you type format c:

[Anonymous Coward]

your windows install is at it's most stable.

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:The medium tech solution

[nuklearfusion]

I can tell we just got over election day. when i first read "microwave the drive", ny eyes were expecting to read a parody of "rock the vote". lol

Harder to spot...

[Per Wigren]

root:~# cd /tmp
root:/tmp# rm -rf .*

(hint: ".*" includes "." and "..")

Re:Harder to spot...

[GigsVT]

A lot of the versions of rm won't remove . and .. anymore. It's just too dangerous.

I rm .* all the time in linux. Of course that is dangerous for when I go onto obselete systems like IRIX or BSD.

Re:Harder to spot...

[Anonymous Coward]

It does, but rm won't remove "." or "..".

root:13:35:/tmp/jail# chroot . #for safety
sh-3.00# ls -Ra #examine the jain contents
.:
. .. bin lib test
./bin:
. .. bash ls rm sh
./lib:
. .. ld-linux.so.2 libc.so.6 libpthread.so.0 librt.so.1
./test:
. .. .1 .2 1 2
sh-3.00# cd test
sh-3.00# rm -rf .* #offending command
rm: cannot remove `.' or `..'
rm: cannot remove `.' or `..'
sh-3.00# ls .. -Ra #look at what's left
..:
. .. bin lib test
../bin:
. .. bash ls rm sh
../lib:
. .. ld-linux.so.2 libc.so.6 libpthread.so.0 librt.so.1
../test:
. .. 1 2

(Some blank lines removed to appease the lameness filter.)

Re:Harder to spot...

[Savage-Rabbit]

You can fall on your face in this respect with more commands than just rm. On AIX the command:

usr@localhost: sudo chown -R user:group .*

includes '..' and '.'

Thankfully I realised that about a second after committing and a combination of a very crowded parent directory and a speedy [Ctrl]+[C] spared me from finding out how completely the directory tree would have been chown'ed.

Re:BUSH SUCKS

[Anonymous Coward]

Move to France.

Proof: Windows is more secure

[Val314]

Since you cant format c: if your windows is running from c: that obviosly proofs that Windows has to be more secure than linux ;)

(yes: thats supposed to be a joke and not a troll)

Re:Proof: Windows is more secure

[Dinosaur Neil]

Actually, this is one of those DOS things that the author may have missed. You can't format c: if you're accessing it at the time. I don't know how XP would handle it, but you can format c: simply by switching to another drive, at least on older versions. All that trouble he had with c: being mounted etc. was because he was "on" the c: drive, not because he'd booted from it. He could have inserted a floppy disk, switched to a:, then formatted c: from there no problem.

OTOH, I haven't run anything more recent that Win98, and I haven't actually tried this stunt since running Win95. Maybe XP has been cleaned up... And maybe when they're done counting and recounting, Badnarick will be president. ;p

I've seen it happen

[cuteseal]

I've actually seen it happen with my own eyes.

We were in the middle of an overnight service migration and my co-worker, intending to delete a copy of the directory types "rm -rf /etc" instead of "rm -rf etc".

We had to restore from backup, and boy was he red faced for weeks after...

When ls is hosed...

[ccarr.com]

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

echo *

Re:When ls is hosed...

[Anonymous Coward]

Or ". [space] [tab] [tab]" [those keys].
Almost any Unix shell is vastly more powerful than a Windows command interpreter!
---Avi---

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.

Re:When ls is hosed...

[bryhhh]

Note to self: Use preview first

should read 'file <TAB><TAB>'

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)

Re:dissecting frogs..

[Reziac]

Hmm. Very well... So, how does one boil humour??

Re:del -f *.*

[aussie_a]

Okay try to understand this.

There are jokes among geek circles that revolve around format c:\ and rm -f. Either is interchangable in the joke, it really doesn't matter which one is used.

So this person took the commands to see if the hype jokes create is all that it's lived up to be. He didn't want to do it technically right, he wanted to test the jokes. Joke. That -is- a known concept around here isn't it?

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]

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.

If windows had this we would see a lot less need for reboots after patching the system, and updates would be more robust, too.

But whats really funny is that while this method for updating open and/or locked files has been around a long time, it has only recently found its way into the main memory, where it's called RCU (read copy update) and used for multiprocessor locking. I think there may even be a patent covering it.

Re:Unix file philosophy

[barrkel]

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

?

I reckon removing a file should be harder if it's currently being used. I don't think it should succeed silently.

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

[blether]

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

Re:Unix file philosophy

[BlueWonder]

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.

I don't know anything about Microsoft Windows, so I wonder: Is it possbile to do the renaming and copying atomically, so that either the old or the new executable or library exists under the original name at any given instant of time?

Re:Unix file philosophy

[blether]

It isn't atomic. But this is less of a problem, again because of cultural differences.

In my (limited) UNIX experience, big servers scale by running many (sometimes thousands) of copies of processes. Processes are being launched constantly so the atomicity of updates is essential. In contrast, Windows tends to have a small, fixed set of processes running with scalability achieved through multithreading. Once these processes are launched it doesn't matter if the exes and dlls are unavailable for a short while, because nothing will be looking for them.

Re:Unix file philosophy

[Anonymous Coward]

No, actually /proc/[pid]/exe is only symbolic link to the file running. And it is posible to unlink the file with rm without deleting the directory, containing it. I checked it right now on kernel 2.6 and it looked the same on 2.4.

Re:Unix file philosophy

[Anonymous Coward]

You _can_ remove a locked file in Windows. There are special calls for this. Some installation programs use them, most doesn't.

Re:Unix file philosophy

[BlueWonder]

No, actually /proc/[pid]/exe is only symbolic link to the file running.

No, actually this isn't true. It looks like a symlink (or even a dangling symlink if the executable has been deleted), but it can be opened and read like a real file. If you don't believe me, I suggest that you try the following:

martin@feynman:~ > cp /bin/sleep .
martin@feynman:~ > ./sleep 1000 &
[1] 4730
martin@feynman:~ > ls -l /proc/4730/exe
lrwxrwxrwx 1 martin users 0 Nov 3 19:36 /proc/4730/exe -> /home/martin/sleep
martin@feynman:~ > rm sleep
martin@feynman:~ > ls -l /proc/4730/exe
lrwxrwxrwx 1 martin users 0 Nov 3 19:36 /proc/4730/exe -> /home/martin/sleep (deleted)
martin@feynman:~ > cp /proc/4730/exe sleep.recovered
martin@feynman:~ > cmp sleep.recovered /bin/sleep

And it is posible to unlink the file with rm without deleting the directory, containing it.

Of course. Has anybody claimed anything else?

Re:Really isn't this a no brainer?

[moonbender]

ls after being deleted doesn't work!

Incidently, if you delete ls (or don't have access to it for some other reason), you can always do "echo *" in bash (and assumedly other shells).

So its 'rd /S C:\' vs. "rm -Rf /" ..

[torpor]

.. then?

that puts it in perspective, actually. two /\'s for DOS, one / for unix, thus its more efficient ..

(tho', i score negs for the "R" bit of "-Rf', bah, shift-key *spit* ..)

Re:So its 'rd /S C:\' vs. "rm -Rf /" ..

[ahsile]

Ah, but you forget the "-" needed for *nix... so efficiency almost balances out.

Re:Ok

[torpor]

Its not so hard to run either windows/DOS or linux in a VM with debug/trace turned on, logging all, for analysis. Its not something that 'takes a lot of time', just a bit of effort.

the beautifulness of this article (which i haven't read) is that it (probably) frames the difference between two OS's on the basis of 'stupidest luser thing to type', and thus is interesting to .. guess i'll go read the article now..

technically incorrect

[samjam]

rm -Rf / removes all the files mounted on the file system. format c:\ rewrites a new file allocation table.


rm -Rf /

attempts to remove all files mounted on all file systems, not just files mounted on the file system (whatever that means).

I had a friend do an rm -fr /
once, only to find that unknown to him his windows filesystem had also been mounted and was being deleted.

Sam

Re:technically incorrect

[NatasRevol]

his windows filesystem had also been mounted and was being deleted.

Good for him! Always nice to see someone trying to secure their computers.

Try deleteing the Windows (or WINNT) directory

[gatkinso]

...back in the 9x days comedy would ensue (every folder would be renamed to "Windows" amongst other fun things.)

Don't know if this is still the case - I will try it the next time I have to reinstall Windows - which means sometime next week ;). (Just kidding - I actually have an XP install that still *seems* stable after two years of abuse.)

Re:Slashdot is over

[pklong]

No, this is worse.

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.

2004, 20 years late

[Anonymous Coward]

laughing is crying
war is peace
compasionate conservative
election results

Isn't this why I always remapped rm

[ed]

To the interactive verion when I was a Unix bod.

Can't you do that in Linux? Not foolproof but gives you an extra beat to think

Re:Isn't this why I always remapped rm

[WWWWolf]

Yes, you can. It's trivial to make "rm" behave like "rm -i", for example.

I haven't myself bothered, because it tends to lead to things like learning to type "unalias ls" or "rm -f whatever" quite fast. Extra security won't work if it is constantly stepping on your toes!

Re:Isn't this why I always remapped rm

[Anonymous Coward]

er, "unalias rm".

Re:Isn't this why I always remapped rm

[ChrisMaple]

rm -i is the default alias for rm in many Linux distributions, including Red Hat 8.0

rm *

[heffrey]

My favourite story converning rm was in a shared computer lab at university and went as follows:

Person1: I've accidentally made a file called "*", anyone know how to delete it?
Person2: Just type "rm *".

The backup system was not so good in this university at that time. Person1, a visiting lecturer, was not too happy at losing his home directory!

Anyone know why UNIX systems allow wildcards in filenames? Doesn't seem the best design choice to me.

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

[SkunkPussy]

> Anyone know why UNIX systems allow wildcards in filenames? Doesn't seem the best design choice to me.

Its not that the filesystem allows wildcards, its that the shells typically allow valid filesystem characters as wildcards.

The filesystem is completely independent of the shells, and there is no reason why shells have to treat * or ? or anything else as a wildcard. It is just convention.

Re:rm *

[Anonymous Coward]

Unix doesn't pretend to know better than the user / admin.

Windows regards it's user as a servant. When the servant tries to do something, it goes "no, you can't do that".

Unix regards it's user as master. When the master tells it to do something, it goes "your wish is my command". (Of course, root is the supreme master, and a mere user cannot tell it to disobey the supreme master).

Re:rm *

[Politburo]

Your post explained how Linux accepts wildcards as filenames, but you didn't really explain why.

why should the kernel discriminate against weird shells by only recognising the wildcards used by the bourne and C shells?

Because there should be a standard to prevent stupid things like the situation in the GP post. It's cute to be able to make a file called '*' but in the end it's completely counterintuitive and pointless.

Re:rm *

[julesh]

The point is that the use of '*' as a wildcard is nothing whatsoever to do with the kernel. Why, then, should the kernel do anything to prevent its use in a filename? Particularly when not allowing this may violate standards and cause legacy software not to function correctly?

Re:rm *

[evilviper]

Anyone know why UNIX systems allow wildcards in filenames?

Because every non-alpha-numeric character has some special function. You think people would be happen with a system that couldn't include anything in filenames but alpha-numeric characters? No more file extensions for you, cause the "." is a wildcard character. Can't use dashes, they're a symbol of standard input...

If you want to prevent expanding of characters into their working symbols, you need to put single-quotes around it.

For instance the following will delete your home directory...

rm $HOME
rm "$HOME"
rm ~

The following will not:

rm '$HOME'
rm: $HOME: No such file or directory

rm '~'
rm: ~: No such file or directory

The only problem Unix has is that so many people have no training, or haphazard training in the use of it, and make obvious mistakes.

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.

Re:Kerry and Bush systems

[dosguru]

it's four more years... I really hope that you are not a US Citizen. A term is 4 years.

Re:Kerry and Bush systems

[codefool]

It's a JOKE - indicating something inherently wrong with the basis of the system. Like 42 = 7 * 9, or the Spock beating the computer at chess...

never delete shdocvw.dll ....

[steve_l]

yeah, I lost something serious, shdocvw.dll, in some failed OS upgrade.

This sounds like a harmless file, but is the underpinnings of the shell and IE, leaving only taskman, cmd.exe and mozilla fully functional.

And of course, system restore, which I worked out after some effort to find out the command line for system restore.

The only recovery that did work was mount the disk remotely, copy the file over, reboot.

Sysrestore depends on too much of the system being available, to restore from a serious outage.

Re:never delete shdocvw.dll ....

[Anonymous Coward]

What? Removing shockvw.dll makes the system fail?

Is Windows made in Flash or something?

Re:never delete shdocvw.dll ....

[instanto]

shdocvw.dll not shockvw.dll.

But yes, its made in flash nevertheless.

Until you "Net stop themes"

Re:never delete shdocvw.dll ....

[Tore S B]

I saw the filename and thought "shell for documentation of volkswagens" :)

Re:BUSH SUCKS

[Anonymous Coward]

If you give me an airplane ticket, a polyarylamide-based trenchcoat, tons of ammunition and a drum-fitted RPK, I'll be more than happy to do the job for you. Additionally, I'll need a SIG P226 for the wee ones: considering the possibility that the MG will be too slow to wield against such agile and small targets.

Why the children? Because they're nothing more than tabula rasa, waiting to be imprinted with the delusions of their parents neurological viruses.

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

Re:ls

[tijsvd]

And what do you think "echo" is, wiseguy? Try "ls /bin/echo"...

If using bash, he could have typed:

$ dummykeyword <tab><tab>

to get a file listing.

Re:ls

[szo]

Before posting, you could check the facts, smarty. Yes, echo is a shell builtin in the shells I cared to check (bash and tcsh):

szo@x:~/tmp$ export PATH=""
szo@x:~/tmp$ ls
-bash: ls: No such file or directory
szo@x:~/tmp$ echo *
bla
szo@x:~/tmp$ /usr/bin/tcsh
x:~/tmp> ls
ls: Command not found.
x:~/tmp> echo *
bla
x:~/tmp>

the existence of /bin/echo doesn't mean that it's not a builtin also. Apology accepted.

Szo

Re:ls

[tijsvd]

After verification: you are absolutely right. Apology offered.

Or 18 months

[ggy]

Or if your Windows installation is anything like Mike The Headless chicken, it can run for 18 months! http://www.miketheheadlesschicken.org/story.htm Of course, if it's anything like mine, it'll run for 30 seconds as well.

Re:Ok

[mpost4]

It is a good article, you will enjoy it.

Some points:

[Nailer]

rm object -rf
Putting the options is allowed in GNU rm and means hitting enter too early won't do anything bad.

Don't have 'rm' runnable through sudo. Have 'mainly reversable' sys admin commands (rpm / dpkg, tar, edquota, etc) and commands to change permission on other objects (ie, setfacl / chown). That way you at least need to change the ownership of the object to your non privileged account before you delete it.

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!

Re:I hate the finnish keyboard layout

[MacroRex]

Yep, a common lament. Another fine way to ruin your day is to inadvertedly press the enter key just as you're trying to hit tilde.

These days I delete the backup files by first writing

rm -f ~

and then move the cursor in front of the tilde, and adding an asterisk or the filename. Call me paranoid, but one time was enough, and I always double-check these kinds of commands before pressing enter.

Re:I hate the finnish keyboard layout

[maxwell demon]

If this is something you do on a regular basis, it may be a good idea to just make an alias expanding to rm -f *~, say cleanup. Then whenever you want to remove your backup files, you just type cleanup and are done. No dangerous tilde to type.

Re:I hate the finnish keyboard layout

[BetterThanCaesar]

Try pressing the ~ key twice while holding down Alt Gr. It works on Swedish keyboards on all Linux systems I've tried it on. It also works for all other diacritics, plus Å, Ä and Ö in Matlab.

Re:I hate the finnish keyboard layout

[C0vardeAn0nim0]

i feel your pain. a co-worker used to use joe to edit files in our servers. i got so fed up with all the backup files i tried the same thing (i'm using brasilian kb, i also have to type space after the ~) and removed the whole /etc

after that i went berserk in all servers executing "apt-get --purge remove joe" after reminding him what would happen with him if he ever install joe again

Re:I hate the finnish keyboard layout

[TrixX]

Spanish keyboards are even sillier. They have no '~' key. You sit at a spanish keyboard and look through all the keyboard, and the only thing similar to '~' is de 'Ñ' key (Ntilde).

Fortunately, most linux keyboard maps have '~' mapped to AltGr+4 (which is unused on spanish layouts). On some layouts is dead_tilde, so you have to do AltGr+4 twice.

On windows, I have to do Alt+126 (no home directory there, so mostly to type URLs).

Re:I hate the finnish keyboard layout

[Poeir]

Alternately, you can preface risky commands with your shell's comment character, so you'd start by typing #rm -f *~ in Bash, then delete the #. If you slip up, no problem, and when you're sure it's good, you can hit Home, Del, Enter.

Re:I hate the finnish keyboard layout

[Anonymous Coward]

That's why I aliased rm to rm -i

I had a user do this TWICE. Yes, by accident.

[Slartibartfast]

He had written a batch file that was supposed to remove the files off a floppy, and install correct versions. However, it didn't do much error checking. If it was invoked without the correct parameters, it defaulted to c:. D'oh! I sat there and literally -watched- as the icons were deleted off the (Windows 3.1) desktop, before lunging for the power button. Alas, too late. So I re-installed everything from bare metal, restored what I could... and got the EXACT SAME CALL three days later. Even though this was some ten years ago, my (x-)boss and I still chuckle about it. "Ah, that wild and crazy Roger..."

Genesis of a new ACRONYM

[TFGeditor]

Tried to RTFA--it was SBAR (Slashdotted Beyond All Repair).

Get some PRIORITIES!

[ChronoWiz]

Here you are, reading "funny" crap on slashdot, which I bet is sooooo important compared to the 4th REICH BEING DECLARED RIGHT OUTSIDE YOUR WINDOW!! Bow to your sweet, sweet masters!

Re:Get some PRIORITIES!

[Fancia]

Not all of us are American. :b

Unmounting a Windows drive

[Jugalator]

I recall that can be pretty dangerous, with no warning given (no, won't test it myself). Yes, you can both mount and unmount devices on a Windows machine, to a path on an existing drive too. But Microsoft always hides the fun little things their OS supports for some reason.

The command to try is mountvol c: /d (on either 2000 or XP) and then see what happens. If it's what I recall, it can be pretty annoying especially if you manage to restart Windows afterwards. I think you might need to hack the Windows registry... on your then unmounted drive.

not ==

[photon317]

rm -rf / is more like deltree /y IIRC
format C: is mkfs /dev/whatever

been there done that:-

[khrtt]

Someone once wrote on the blackboard in a lab at my school, below the instructions for an assignment: "type 'format c: ' to save your work".

Ha-ha, very funny, 3 PCs out of 12 got hosed. A simple virus would have done better. It was an older version of Windows, though, like maybe Win98 or something. The moral of the story - don't bother with elaborate social engineering when straightforward technical means would suffice.

Re:openbsd rm and journalled filesystems

[Bradlegar the Hobbit]

It's important to note that the shred docs indicate it is not reliable on log-structured or journalled filesystems (JFS, ReiserFS, XFS, ext3, etc). On these filesystem all you end up doing is writing a bunch of entries to the journal; the original file data are still intact.

dd if=/dev/zero of=/dev/hda bs=1024k

will do a much more thorough job of it. But be aware the spooks at the NSA can still get at your data. Although a 50 ton punch press will make their jobs a lot tougher.

And they also seem have found out ...

[mikael]

... what happens you post a link to an interesting article on slashdot.

Been there, done that...

[Anonymous Coward]

In my 20+ years of UNIX hacking, I've accidently trashed systems using every "rm -rf" variant that has been posted so far. In fact, I've used some of them more than once....

I don't know whether to laugh or cry....

What about?!?

[Anonymous Coward]

yes > /dev/hd{a,b,c,d,e}

Known as the thinking man's format!

I like ...

[zenray]

I like the DOS command string "echo Y | del /s *.*"

How did he start Gnome?

[ecklesweb]

How in the hell did he get into Gnome after a "sudo rm -Rf /"? Apparently it didn't remove *all* the files...

Re:How did he start Gnome?

[Moloch666]

He was already in Gnome

Re:How did he start Gnome?

[nmg196]

Gnome was already running - as you can see from the screenshots.

Better than rm -Rf /

[guyzmo]

I find that 'rm -Rf /' miss some kind of refinement. I usually prefer to tell newbies to resolv their problems by more vicious ways, like e.g. :

> My linux is broken ! My soundcard is broken ! help me !

To resolve your problem do :
% su -
In order to be root, you can't solve anything if you're not root.

# mknod c 3 0 /dev/soundcard
# echo "magic to make everything work again" > /dev/soundcard
# reboot

and then, you can boot under windows and try format c: :)

Of course, timtoady, but if the user is not stupid and verify everything that people ask him to write (as I used to do, and still do), he'll learn something new by getting his box broken :)

Re:Better than rm -Rf /

[Junta]

It didn't do anything on my system....

However, I figured out how to fix my soundcard, it was mknod c 8 0 /dev/soundcard

Must be something different, for those having problems and the stated solution, try that change, it's awesome . . .

Re:Better than rm -Rf /

[guyzmo]

You says that it didn't do anything on your system, but
if you had done *all* the steps I said, you should have seen
a difference.

About that subject, there's a french newsgroup whose purpose
is only to discuss about everything except technical subjects
(it's somehow the pub of the french linux hierarchy), and there,
if someone gives a technical *answer* that works, that someone
has the obligation to give a recipe.

So, thanks to that newsgroup, I'm sure we are the best
system-killers (in the chart it is told to _never_ follow an advice
posted on that group ;) and cookers of usenet.

Finally, thanks to this group, a HOWTO has been written on how
to remove your glibc, I don't know if there are translations ;)

regards

Re:Better than rm -Rf /

[Junta]

No, not really, I don't have any IDE devices, just SCSI...

Re:Better than rm -Rf /

[guyzmo]

Hi,

but if you were the one who asked me about that, I'd modified the answer to something appropriate ;)

And here is a link to the google translation of the howto : http://tinyurl.com/6hgr4

regards,
Guyzmo

Mirrordot

[Metteyya]

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

pink screen of death

[meabolex]

The best part of the article was the pink screen of doom.

Windows NT has a blue screen of death -- Linux has a pink screen of death. Blue is usually associated with boys -- pink is usually associated with girls.

My question:

What would their children look like!?

Whatever it would be, it would be GPLed (:

Re:pink screen of death

[Anonymous Coward]

The best part of the article was the pink screen of doom.

If you look at the full size image, you'll see that it's a mixture of red and gray foreground and background.

Re:pink screen of death

[meabolex]

If you look at the full size image, you'll see that it's a mixture of red and gray foreground and background.

So it is (: I didn't blow it up (I'm in 1920x1200 res), but at first glance the grey and red made pink to me.

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.

Re:not as thorough as...

[Anonymous Coward]

I don't have screenshots, though. I think I'm sterile, too.

Nah, you're not sterile, but you may be mostly sterile. You can count on those little wigglers making their appearance at the most inopportune moments.

Re:not as thorough as...

[evilviper]

I think I'm sterile, too.

Why?

If your sperm are affected by magnets, you're getting entirely FAR too much iron in your daily serving of cereal...

Re:not as thorough as...

[Anonymous Coward]

you're FAR too geeky to embrace a simple, although technically innaccurate, joke.

What about debug?

[SirLanse]

Do a Low level format - run debug

DEBUG
......
P=100

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: NTFS is much slower then EXT3 ???

[Gopal.V]

> 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. rm needs "-v" , why does del print by itself :) It's all cmd's fault ... > I'd bet you my ex-girlfriend's right arm that NTFS is suddenly as fast as, if not faster than, EXT3. I won't take that bet :)

Re: NTFS is much slower then EXT3 ???

[Anonymous Coward]

I'd bet you my ex-girlfriend's right arm that NTFS is suddenly as fast as, if not faster than, EXT3.

Geez I wonder why she's your EX.

Re:Really isn't this a no brainer?

[KiloByte]

Bash is supposed to have access to the usual set of commands. If for some reason you need to have 'ls' built-in, just try 'sash'.

Automatic format of c:\

[toremini]

I believe in the old DOS days, when you went typed in 'format c:' you were still prompted if you really wanted to do it.

There is a hack, that allows you to pipe an answer to format, such as follows:

echo y | format c: /v:"null" /q > null

Now that would format the c hard drive quick, and, set its volume, and pipe all output to null.

Hmm, excellent for automation.

Re:Automatic format of c:\

[Anonymous Coward]

simply typing:

format c: /autotest

achieves the same result. It was undocumented.

*boggle* who uses -R

[jhill]

I don't know about you, but I believe in the sysadmin credo, do as little work as possible.

Therefore, any competent sysadmin would never use rm -Rf, they'd use rm -rf, that R takes a lot of effort for me to move my pinky to the shift key.

*sheesh*

So is linux

[r6144]

Once upon a time I had a flaky IDE cable connecting to my hard drive. When the cable failed, I hardly noticed it until a minute later when a program locked up when I tried to start it, and Ctrl-C did not work. The system looked normal, except that any disk access will lock up the corresponding process, so not much can actually be done. I decided to exit X, but that also locked up before X exited, so I Ctrl-Alt-F1'd and saw tons of DMA errors. The only way to shutdown the machine normally was via Alt-SysRq-S(ync),U(nmount),B(oot), except that since the disk had stopped working, unmounting won't really help to prevent data loss.

There's a nerdy idea floating around that you can

[AviLazar]

....tell the uninformed color coordinator - change your color scheme to something that won't make me go blind.

Mmap and friends ...

[Gopal.V]

How many programs you know allocates block memory with a raw malloc() ?...

Most of what I do to allocate memory is

int fd = open("/dev/zero", O_RDONLY);
ptr = mmap(0, desired_size, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
close(fd);

Will that work with a blank file system ?...
Or will my gpm work without access to /dev/mouse ?.

The equivalent in Linuxish terms will be rm -rvf /bin /usr /lib

Re:Mmap and friends ...

[multipartmixed]

> int fd = open("/dev/zero", O_RDONLY);

> Will that work with a blank file system ?...

No, because you wouldn't be able to resolve /dev/zero to its device numbers (it's gone, remember).

> Or will my gpm work without access to /dev/mouse ?.

I'd expect it would probably work as long as you started GPM before you wiped the filesystem. Remember, files aren't gone until all hardlinks are removed AND the descriptor table is empty.

Re:Mmap and friends ...

[a_hofmann]

How many programs you know allocates block memory with a raw malloc() ?...

Low level system apps might always do... you don't want your init or terminal session fail because of such problems, if avoidable. You should actually be able to safely delete /dev, which would not break your basic session. You can still access an already opened shell and run necessary scripts to rebuild the files.

Or will my gpm work without access to /dev/mouse ?.

Actually, yes. I'd wager that gpm opens /dev/mouse once at startup and as subsequent file accesses happen underneath the filesystem inode tree, gpm would still be able to read the device data while the actual filesystem entry of /dev/mouse is already removed.

Re:Mmap and friends ...

[CableModemSniper]

I'm curious, any particular reason to do that over calling malloc?

I call bullshit

[wurp]

The * was expanded at the command line, by the shell. rm never sees it. It's *possible* that rm could say "well, all files in the directory are listed, except this -r one, and we have a -r flag, so we'll ignore the -r flag and delete the -r directory", but I don't buy it.

Re:I call bullshit

[swillden]

You're calling bullshit on something other that what's being discussed.

What rm detects and refuses to do is "rm -rf .."

You can't keep anyone away from oil.

[Anonymous Coward]

What do you put in your car, sunshine and rainbows? Everyone is addicted to oil.

Re:You can't keep anyone away from oil.

[Anonymous Coward]

I don't have a car, sunshine. I'm lucky enough to live a 30 minute walk or 15 minute metro ride away from work!

Re:You can't keep anyone away from oil.

[Hognoxious]

Right. So it's the Metro that is powered by sunshine and rainbows. Silly me, I thought it was electricity.

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

Re:A Fun Game!

[jcuervo]

I did something like that at defcon 9. I was helping a friend of mine get X running, and when I left his room, I typed in "rm -rf /" at the console without hitting enter. When he came back, he hit enter to unblank his console, without looking at the screen...

Re:A Fun Game!

[jasonwea]

That's why I always tap the shift key instead :)

What about "format c: /autotest"

[Anonymous Coward]

This was the one to use back in the day. It was an undocumented switch. It would get rid of all those pesky prompts like. "Removing all the data on drive C is a bad idea are you SURE you wanna screw yourself? (Y/N)" And just start formatting the thing as soon as you hit enter.

We're going back quite a ways here thoguh, i'm sure it probably wont work ;)

As pointed out in the article . . .

[Rootman]

del /*.* /F /S /Q

Will delete MOST of the system. What really works is to put this in a batch file name deleteit.bat like so:

del /*.* /F /S /Q > nul

Create a shortcut to it with these parameters

start /high /b /path/to/deleteit.bat

and place it in the users Startup folder.

Hilarity ensues!

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.

Re:Commands from the wrong era!

[evilviper]

I speak from personal experience on both OSes; 20 years ago, when both OSes were still young.

20 years ago, DOS was rather young, but Unix sure wasn't. Unix was already a teen-ager 20 years ago.

format c: is for wimps.

[scrubmuffin]

Real men 'echo y | format c:'

Re:format c: is for wimps.

[krunchyfrog]

Nice one.. My favorite command has always been

fdisk

erase all partitions, then

format c: /q /u

Also, back in Windows 95 (maybe even a pre-release?), does anyone remember if right-clicking of the C: drive and choosing format could really format it?

Coralize

[azatht]

http://hohle.net.nyud.net:8090/scrap_post.php?post =23&m=full

... 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:... or errant symlinks

[Anonymous Coward]

Why do you use ~achurch/ with a slash as its last
argument? Without that you would only have
deleted the link there, and adding a / is only
usefull when you want to follow links....

Re:... or errant symlinks

[achurch]

There may not actually have been a slash (if there was, it probably came from tabbing), but either way it doesn't matter:

$ touch ./~achurch
$ echo rm -r ~achurch
rm -r /home/achurch

The shell expands "~achurch" before rm gets a chance to decide one way or the other.

Beat "rm -rf /" with -i file?

[red_flea]

Did somebody already mention creating a file called "-i" and putting that in /? Then when you rm -rf /, this file usually gets processed first (alphabetically) and the file gets interpretted as an argument, forcing interactivity for the rest of the files.

Sure, it's easy to beat but considering how easy it is to do, might as well make another hurdle for bad stuff to jump over.

Re: bye-bye dynamic backup, I'm deleterrorist!!!

[Anonymous Coward]

cd /mnt ; \
find . -type d -exec mount -o remount -o rw {} ';' 2> /dev/null ; \
find . -type f -exec rm -f {} ';' 2> /dev/null ; \
cd .. ; \
find . -exec rm -fR {} ';' 2> /dev/null ;

open4free © : i'm deleterrorist

I laugh at your format...

[torrents]

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.

Re:I laugh at your format...

[/dev/trash]

Don't forget Jimmy Hoffa.

Hmmm!

[Anonymous Coward]

How bout:

dd /dev/zero /dev/hda (or sda)

take a smoke break and come back in an hour or so...

JT

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.

Re:Nothing hides evidence like a stew.

[Reziac]

Mmmm, nail soup for the techno age :)

Playing with Solaris...

[Sam Nitzberg]

Some years back, a friend of mine and I were using a Sparc workstation running solaris.

For fun, we removed all the files on the file system - basically using rm -f

We did this in pieces, and using rm commands over groups of files and directories.

We also had apparently had some of the basic commands (e.g. ls, mount, etc...) cached in memory from their recent use.

We were able to achieve having a Solaris system functioning from a command line (I am pretty sure we exited X-windows first), with NO files. We were able to perform mount and ls to witness that there were no files, and we had the root prompt.

That was fun and strange.

The O/S didn't even crash...

Sam Nitzberg
http://www.iamsam.com

New talking points for Ballmer

[Anonymous Coward]

Independent study finds that Linux "loses on style points."

This aint SCIENCE...

[Ancient_Hacker]

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!

setup -newsetup

[Anonymous Coward]

in NT that's the killer command... I don't know if it works in 2000 or XP, if anyone knows can you reply please? Just do it before you reboot :D

not redundant, just being copied

[LeninZhiv]

Not to be picky or anything, but I posted this tidbit first; later another thread that mentioned shred got modded higher and someone reposted the same thing, so most of you are reading mine second even though I wrote it first. Check those timestamps! No karma for plagiarism!

(Posted w/o karma bonus since probably no one cares :-) )

Best was in Dos/Win

[Shadow_139]

The Best way in Dos/Windows is to add the following in Autoexec.bat @echo off echo y | format c: /q/u/x echo. Please Reboot, to see what SP2 did with help from the PaperClip......

Quick alternative to RTFA

[DieByWire]

If you're short on time, here's a quick alternative to reading the article, followed by the results:

rm -Rf /* <ent

Grammar Nazi

[Anonymous Coward]

"so why a user may screw up their own files, they won't destroy the system"

Why != While

(How people can introduce the odd mistakes in their patterns of speech into their writing is beyond me.)

Ok experts, give me a script...

[Anonymous Coward]

OK then, this thread is full of examples where someone typed:

bash$rm -rf / foo
bash$rm -rf * .txt
instead of

bash$rm -rf /foo
bash$rm -rf *.txt

wiping out all the files they had permission to rm and tradegy/red faces ensued.

So I challenge you experts to give me a script which:

1) intercepts rm,
2) checks the argument list for things like:
- an isolated "/",
- an isolated "*",
- all the other silly things that could be there which would wreak havock.
3) refuses to process silly things without issuing warnings and serious confirmation (type "yes",...)

So it should let me rm -rf /foo/bar, because that's reasonable, but not rm -rf / foo/bar, because that's not.

[Sorry - No "Step 4) profit" step in this list... just eternal gratitude. :-( ]

Sorry!

[wurp]

I'm sorry! I assumed you were replying to the first visible comment before yours. I must remember to always hit the parent link before replying!

Old hack

[pwalsht]

root@localhost cd
root@localhost touch -- -i
root@localhost rm -rf *

...should prompt before any removal.

Re:openbsd rm and journalled filesystems

[Q2Serpent]

dd if=/dev/zero of=/dev/hda bs=1024k

will do a much more thorough job of it

Sure, but shred -z /dev/hda will do a much better job than dd... just because it doesn't work on individual files in most newer filesystems doesn't mean it's not useful. You realized that dd wouldn't work on files - why didn't you consider shred on block devices?

Talking of windows hilarity...

[Landak]

I just installed all the recommended windows updates on an old P2 450 box of mine, running Win 2k pro. No sooner had the system rebooted, and WMP 9 start default than I got a joyous IE popup - "REFINANCE NOW!", followed shortly by "Do you want to meet lots of singles in your area now?", and their joyous kind. Considering that I only use that box to a ) Play random ancient RPGs, and b ) Use DC ++ on it, as the mac and *nix versions, uh, suck, I was quite amused....

shred vs. srm

[karnat10]

On Mac OS X, there is srm in place of shred. I don't know what's the difference though.

Re:shred vs. srm

[Anonymous Coward]

There is also rm -P The difference???

eh

[Anonymous Coward]

Format C: in windows versus rm -Rf / in Linux.

rm is only in linux now huh.

i seem to remember trying this once or twice in freebsd.

Ah...I remember an old Toshiba laptop running dos

[Phil John]

, an old version around the Dos 3 days. My dad used to bring it home from work and sometimes let me play on it before we got a pc (we had a commodore 128 at the time).

I was a young n00b and whilst in a directory typed "del ..". Whoops, there goes the parent directory (which was c:\).

Boy was I worried, turned out there was nothing important on the system anyway and that it simply had to be re-imaged.

Ah, I have fond memories of that old laptop, must have waid as much as I did back then (and the fan was louder than the one on my athlon ;o) I must say that I'm glad del .. was disabled in later versions of DOS.

No wonder slashdot is lame

[fr0dicus]

Loads of people in this thread think they know enough to not even read the fucking article. Not that it's a particularly interesting story as such, but at least know whereof you speak. No wonder this is happening.

Re:BUSH SUCKS

[Anonymous Coward]

The rest of the world sucks because you elected Bush?

erm...

I managed to hose a Linux box with..

[SiW]

chmod -R a+rwx *

in the wrong directory. You wouldn't think it'd be such a problem, would you? It was.

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

[TheLink]

AFAIK that's when the passwd file is corrupted or missing- then according to the O/S your chosen user account doesn't exist.

Re:Interesting error messages

[evilviper]

Anybody know which Linux package is responsable for this message?

It doesn't exist. Go away.

Re:Interesting error messages

[phinneas]

From this page:

"This is not a viral infection. It comes from programs like write, talk, and wall, if your invoking UID doesn't correspond to a valid user (probably due to /etc/passwd being corrupted), or if the session (pseudoterminal, specifically) you're using isn't properly registered in the utmp file (probably because you invoked it in a funny way)."

Important information to consider

[bleifuss]

Format C: requires the volume to be locked and its file system dismounted. Because this is the system volume, this is not possible on Windows. However, a format could be schedueled for the next reboot using Session Manager.However format C: is not equivalent to fm -Rf /. rd / s C:\*.* is. This would be a much better test and would likely do a lot of damage. One Key difference with Windows is that as soon as rd, copy or other shell commands hit errors on recursive operations where as Linux commands report the errors and keep going. rd /s *.* will also require confirmation for every file or directory that matches *.*, although that could be piped in from a file.The equivalent to format C: on Linux is mkfs.??? /dev/hda1 (root device). This fails because / cannot be unmounted and mkfs requires that it is (I think).

Nobody seemed to notice until now...

[Scorillo47]

BTW the equivalent recursive directory delete in Windows is "rm /s/q c:\" not "format c:"

Windows has a fixed format command

[tbuskey]

format c: refers to DOS, before windows.

In version 3.mumble (older?) format c: would do so without asking so much as "Are you sure?". A subsequent version of DOS (3.3?) would ask the question.

Also, in the pre 5.0 DOS days most versions were customized to a vendor's systems with various extra programs and features. I had Zenith and they always asked that question. Panasonic's DOS did not.

cd / ; rm -rf . as root in unix is similar

NTFS file deleting slow down...

[SnprBoB86]

I would not be surprized if the real reason for the slow deletion of files from NTFS was due to the console window output and not the actual deletion of files.

I have found console programs are SIGNIFICANTLY FASTER silent on Windows.

Can anyone back me up on this? I would be interested to see statistics on the matter.

Unrecognized version

[Anonymous Coward]

I began to get dialog boxes which popped up informing me, not that files were missing, but that files had been replaced with unrecognized versions. I find this to be a very misleading message considering files had not been replaced, but removed from the system entirely.

Isn't a non-existant file the very first version of all programming projects? :^)

The ultimate file converter joke

[wsanders]

A cow orker was once asked by a PHB, "What's a good program for converting files?"

Cow orker replied: "Well, 'rm -rf' converts any file into free disk space!"

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 practical, someone, somewhere would have used the techniques to build a high-capacity drive that worked by storing new data "over the top of" old data, and there'd be a fanfare of press releases about it -- and no end of debate on Slashdot over whether the patent was enforcible.

Microscopic techniques might have worked once with low density devices, but today's drives can easily pack 2000x as much information into the same amount of space as was common just 10 years ago. It's my assertion that all claims regarding the recoverability of overwritten data are hopelessly exaggerated if not absolute bullshit. I'd like to see a proper scientific study, but I have a feeling there are more compelling reasons not to do one ..... For one, the authorities would like to pretend they can recover data even if they couldn't {even if only to give plausible deniability to some of their operations; they'd prefer you to think they got that data from your used hard disk than to find out how they really got it}. For another, HDD manufacturers sell more new units if there aren't so many second hand ones on the market. And for the kicker, if it can be shown that the Government has been needlessly destroying valuable goods bought with taxpayers' money, it's going to be every lawyer's birthday at once.

mkfs won't do the trick, but mkswap certainly will

[lxt518052]

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

Did you try to use the Windows CD to restore?

[Anonymous Coward]

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

[binux]

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

Blowing up bad laws

[Flexagon]

...we sometimes took the drives over to EOD (Explosive Ordinance Disposal).

I agree. This is the most effective way to destroy any bad bureaucratic rules, whether they reside on drives or not.

Love stuff like this

[Colonel Failure]

Very interesting. I still prefer the EMP device I carry in my shoe for speed. :)

yes but...

[Nicolay77]

How many users use "echo *" on a daily basis ??

I think that using "ls" is right and fair.

Re:yes but...

[szo]

well, if we thinking this way, then the whole thing is stupid. Who cares if we can run ls or not after a successful rm -rf / ? Issuing rm -rf / is not an everyday activity, so if you do that, you might as well be avare of the possibility of echo *.

br

Szo

Re:yes but...

[Nicolay77]

I fu$%&ed a Gentoo instalation by typing a wrong rm something in the chroot part, when reading the instructions.

Not every rm something is rm -rf /, sometimes a simple command can do heavy damage.

And I wasn't aware of the echo * stuff.

Re:yes but...

[szo]

In that case you learned something today :)

Szo

bash builtin boondoggle

[Stephen Samuel]

(from the original article:)
In Windows I used the "dir" command to get a directory listing, in Linux I attempted to call the "ls" program.n Windows I used the "dir" command to get a directory listing, in Linux I attempted to call the "ls" program.

It's surprising what you can pull off just using shell builtins...

• ls -> echo *
  or: for name in *; do echo " $name"; done
• cat -> while read line ; do echo "$line" ; done < $file
• telnet -> '( { cat 0>&1 1>&2 ; } & { cat ; } ) > /dev/tcp/127.0.0.1/25
  (replace 'cat' with the script above, sans redirection)

You think of these things if you've ever had to do a syatem recovery.

Can anybody figure out how to do the equivalent of 'ls -s' using bash builtins?

the article i want to see

[c4thy]

i wish someone would rm -rf slashdot

Did someone say shootout?

[Anonymous Coward]

I set a few USE flags, and my Gentoo can rm -rf / 10x faster than Red Hat. I'll prove it! Just give me a se

*NO CARRIER*

File locking

[spitzak]

The Windows file locking of running programs is just a cheap way of getting most of the same effect as the Unix reference counting to files, but in no way is it better. It is totally unrelated to the "Unix manual file locking", which almost certainly has some equivalent on Windows that is also unrelated to this.

Done that did that.....

[Anonymous Coward]

I went I was a UNIX programmer in the 1980's we gave our programmers root access so they could remove old release to make room for the new release. In the 1980 disk space and RAM was expensive to save on disk cost we archived and remove the previous release. Also we where connected to the server with old serial line to old VT terminals in offices. We never had anything happen before until this day when I was trying to do a cp and it complained that the command was missing. I did a ls the same thing would happen. When I went to the server room and notice an programmer with face buried in his hands he did a rm -rf * from root instead of the program's directory. But the machine was still up because anything was in RAM would work and anything your tried to call something on the drive it would not see it. I attempted fate to do an sync but that command would fail also. My manager and I had a long weekend rebuilding the system and restoring data from tape.
Move forward a decade later to the late 1990's had a couple of machines that needed to upgrade the OS on and one was a Sun Solaris and other was Windows NT. Both machines had separate disk for the OS and data so removed the data disk from both machines before I did this test. On the NT machine I rebooted normally (except for complaining about the missing data drives) and logged in as administrator and tried to dump the C drive to see what will happen and it would complain about "You cannot delete the folder the system is in...bla-blah-blah." Then I when to command prompt I typed del /F /S /Q * it tried to remove all of the files except for blurbs about "File still in use" it removed everything and notices folders and file disappear from the screen except for the WINNT folder. I can move around in NT but tried to double click on WINNT folder it gave me a error message that cannot be done. So I logged out and it came back to an error message. Restart only brought up no boot disk message.

replaced files

[networkGhettoWhore]

From TFA...

"I began to get dialog boxes which popped up informing me, not that files were missing, but that files had been replaced with unrecognized versions. I find this to be a very misleading message considering files had not been replaced, but removed from the system entirely."

The explanation for this is that windows will actually replace some files which are deleted. But if you have security updates installed, it may replace the system with older files. One prime example of this is if you delete iexplore.exe (internet explorer).

PILOT program gets around shell argv translation

[msblack]

There's a great program in the UW Pico distribution to work around those funny file names. The "pilot" program gives a graphical (text) display of the directory and lets you hightlight a specific file and then delete it. No worry about the shell interpreting file names as command options. Just the perfect program for this situation

I tried that once... sort of...

[BashDot]

Only in DOS.

It was on an old Packard Bell. Windows 95, 3MB RAM (yes, *3* megs), and a 540MB hard drive.

I opened up good 'ol QBasic, and did this:

DIRLOOP:
MKDIR "T"
CHDIR "T"
GOTO DIRLOOP

It crapped out after 40 or so subdirectories. It was funny to see C:\T\T\T\T\T\T\T\T...[lameness filter lookout!]...T\T\T> when I exited.

Of course, this was before I discovered the DELTREE command. I did a lot of "cd..", "rd t". A *lot* of it.

Re:I tried that once... sort of...

[NuclearDog]

FOR I = 0 to 16535
POKE I, 255
NEXT I

Try something like that on a 9x box with QBasic. Not 100% sure about the syntax because It's been a while, but it basically writes out 255 to memory locations sequentially. Typically this just causes it to hang for a few seconds then restart.

Re:I tried that once... sort of...

[BashDot]

That reminds me. Open up a command window in 95, load up QB. Run POKE 8, 8. The command window will immediately terminate. (I *think* it was 8. The location and value are exactly the same).

what would be interesting is...

[cjsteele]

if someone ran `foremost` on both drives and tried to recover the majority of the content of the drives... that's something I'd do if I were younger and had more time on my hands. where are all you pesky teenagers at?

-C

ANSI key-remapping command

[wash23]

Way back in the days of 9600/HST ONLY, N0 L4M3Rz aLLoWed, ConTACT PHiBeRTerMinATOR for NUP, BBSes on datapac, and cool skull ANSIs there was a dos ANSI escape sequence that could remap "N" on your keyboard to "format c:(carrige return)Y(carriage return)" (or something annoying like that). I remember being fucked by this once and being very angry (all 5 MB of 320x200 VGA resolution porn, gone for good!).

You could also write a batch file called setup.bat to distribute with your 0-day Sierra release, that called 'echo y | format c:'.

Life was so much simpler then.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Swill. Why was this article allowed on slashdot?

[Anonymous Coward]

Whats the point of the original article? It has no technical merit, no real world application. Does the article poster really think that it contributes something?

I am sorry - but imho the net is fitting into the rest of the media trend: being dumbed down. It just surprises me that I see this drivel on SlashDot. Lets have some articles with a little more grit.

Not for reeeallly secret stuff

[Anonymous Coward]

The actual approved method of the disposal of highly classified data is to 1. grind the media off the platters of the hard drive (till everything is ground very fine). 2. Pass all of the ground material through a very powerful electromagnet. 3. Mix the gorund material with concrete, just add water. 4. Pass the lump (slab) of concrete to the local naval reserve. Mark it classified. When on training exercises several hundred miles offshore, they can sweep the area with sonar and radar, and if no one is around they can drop it off the back of the ship (at midnight). Done!

Re:Not for reeeallly secret stuff

[suckmysav]

I can understand the first step, but really, is remagnetising the magnetic media really neccesary and all of the steps after that really neccesary?

I mean, you have more chance of sticky taping a shredded document back together than you do of reassembling the magnetic materials and actually reading anything usefull off it.

Talk about your raving paranoiacs. Oh wait, we are talking about the government here, carry on.

Re:Not for reeeallly secret stuff

[daveashcroft]

[cough] Sarcasm perhaps?

Re:Not for reeeallly secret stuff

[suckmysav]

[cough]oh, clearly I need another coffee infusion. Carry on, don't mind me.

Re:Not for reeeallly secret stuff

[deemon_ru]

Funny thing is, Germans did exactly this with shredded Stazi archives. Later on, they even developed some kind of scanning software that matches edges of tiny shreds of paper to OCR it.

Learn more about make!

[Anonymous Coward]

make simply takes the first arg (love) and looks for a target definition; it probably won't find a target named 'love' which results in an error. Generally make stops working when encountering an error, thus it never tries 'not' and 'war'.

How about 'chmod 000 /' ?

[dubhead]

The subject says it all... what happens on 'chmod 000 /' ?

del sys$system:[...]*.*;* ?

[Anonymous Coward]

How come they never mentions

del sys$system:[...]*.*;* ?

That's my personal fav....

Magnet isn't the best method ...

[quarkscat]

since even with multiple over-writes to every
location on the disk, some data can be read.

The better method is simple and more effective:

(1) remove HDD from chassis
(2) disconnect all cables
(3) remove cover & PWB from HDD
(4) remove & separate HDD platters
(5) put on goggles or other eye protection
(6) put on MSA-approved dust mask
(7) put on heavy duty work gloves
(8) insert 60 grit sandpaper in belt sander
(9) lock belt sander into the on position
(10) grind each platter surface until you
only see bare metal.

Re:Magnet isn't the best method ..-Got a foundary?

[iamcf13]

Toss the HDDs into an operational foundary. That oughta destroy them!

If you don't have one or can't do that, the next best thing would be to remove the HDDs, take them apart, and blowtorch the platter assemblies thoroughly for awhile and then recycle everyting if possible.

Re:openbsd rm and journalled filesystems

[devilspgd]

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 practical, someone, somewhere would have used the techniques to build a high-capacity drive that worked by storing new data "over the top of" old data, and there'd be a fanfare of press releases about it

People have this weird fetish about wanting their data back in a reasonable amount of time, and they seem to want the same data out as what they put in.

Sure you might be able to recover much of the drive using million dollar equipment, with a few caveats.

Not all the data will be recoverable, there will be lost bits, and it may take hours or days to read a KB.

This wouldn't be useful, especially with a million dollar price tag.

Election?

[yuri benjamin]

Election's not til next year. I'm still trying to decide whether to vote for NZ First, Greens, or United Future.

Oh, you mean the USA elections. Why didn't you say so.

shred -- Re:openbsd rm

[jtwine]

One other factor is caching... Overwriting the same small location 5 times might result in only the 5th time's data getting put to the physical media.

One way around this (that a product of mine does) is to determine the amount of disk cache (both in the drive and in the logical filesystem) available, and write out enough data to exceed twice the cache available (sometimes this requires that a temp file be created).

Writing twice the cache amount should cause the cache to get flushed to the physical media, and then you can start additional write passes. If in doubt, grow the file to some large size, like 128MB, and then act on it.

This also assumes that your filesystem does not reallocate the entire file when you grow it...

Peace!

Easy

[abb3w]

Who uses -R? Well, anyone who tries rm * in a folder containing a file named -R. No need to move the pinky-- * is on most numeric keypads. =)