Man Deletes His Entire Company With One Line of Bad Code (independent.co.uk) 460
Reader JustAnotherOldGuy writes: Marco Marsala appears to have deleted his entire company with one mistaken piece of code. By accidentally telling his computer to delete everything in his servers, the hosting provider has seemingly removed all trace of his company and the websites that he looks after for his customers. Marsala wrote on a Centos help forum, "I run a small hosting provider with more or less 1535 customers and I use Ansible to automate some operations to be run on all servers. Last night I accidentally ran, on all servers, a Bash script with a rm -rf {foo}/{bar} with those variables undefined due to a bug in the code above this line. All servers got deleted and the offsite backups too because the remote storage was mounted just before by the same script (that is a backup maintenance script)." The terse "rm -rf" is so famously destructive that it has become a joke within some computing circles, but not to this guy. Can this example finally serve as a textbook example of why you need to make offsite backups that are physically removed from the systems you're archiving?"Rm -rf" would mark the block as empty, and if the programmer hasn't written anything new, he should be able to recover nearly all of the data. Something about the story feels weird.
Three words (Score:5, Insightful)
Offsite, offline BACKUPS
Re: (Score:2)
Multiple off-site backups. Multiple, rotating off-site backups. Weekseven if something happens to the on-site tapes you've still got backups.
Honestly, WTF is it about the PC/Internet mentality that makes sysadmins soooo stupid? Enterprises figured this out FIFTY YEARS AGO.
Re:Three words (Score:5, Insightful)
That's all great, but even a less complete, sloppy backup system would be an improvement here.
Another thing people don't understand about cloud hosting... you should still have your own self-managed, non-cloud server that holds your images and ideally runs your service during the low-traffic hours. Whatever your daily lowest traffic 6 hours is, in most cases, should be traditionally hosted. Cloud is super-duper-awesome-webscale for the peak traffic, no way around that if you have peak traffic hours.
Personally, I can re-deploy (including the latest database backup) from my dev workstation using a simple rake task.
Another problem is; relying on your hosting company for backups. Never do that. The same fire/earthquate/bash script/volcano that makes the backup necessary, would destroy it! Expect the hosting company to have insurance, don't expect them to care if your data gets lost. Especially if it "user error."
This has nothing to do with "PC/internet mentality" and everything to do with the latest anti-waterfall, anti-planning, 80% is all that matters mindset. Traditionally, this was easily solved because there was an engineering mindset.
Re: (Score:2)
In this context, the guy is the cloud provider. His customers, if they're sensible, will have their own backups and so will be able to recover, but they also won't trust his business much if that's their recovery strategy from his incompetence.
Even with online backups, there's no way that this should happen. The backup system should be taking read-only snapshots at periodic intervals, so even if you rm -rf you'll only delete the live data and be able to revert to the snapshot from an hour ago.
Re: (Score:3)
In my experience, most of the customers of small hosting companies are paying for fully managed servers, which includes the backups. Most of the customers won't have any backup other than the code they started with. And they wouldn't know how to make a backup any more than they would know how to shoot a fireball spell out of a chopstick.
This is compounded by human nature applying "trust" based on the quality of the personal relationship you have. If you have a nice conversation, by the end they really reall
Re:Three words (Score:5, Interesting)
... are you suggesting that there's someone out there that knows how to shoot a fireball out of a chopstick?
please elaborate on that
Re: (Score:3)
You'll only get the chopstick wand fireball spell when you achieve level 5 Sys-Admin.
Re: (Score:3)
Traditionally, this was easily solved because there was an engineering mindset.
You seem to be implying that data loss was less common in the "Good ole' days", when all sys admins were highly trained engineers. That is almost certainly untrue, and based on false nostalgia. Backups are much easier today, with reliable high-capacity storage, journaling file systems, ubiquitous connectivity, and plenty of off-the-shelf software solutions.
Re: (Score:3)
Some projects I worked on in the 90s still have tape archives of that data.
You can easily have a situation where the backup tools have improved, and there is less overall data loss now, but that the mindset now is sloppy and leads to a lot of errors of types that were less common in the past.
In the past when you did it sloppy, you'd get called out on it; and sometimes it still sucked, because PHB. But when that was the case, it was at least known and accepted that it was technically inferior to not have cor
Re: (Score:2)
Where did you work where that mentality didn't exist? I worked for quite a few very large organisations back in the day and "put it live, we'll fix the bugs as we go" was the order of the day, usually after 2 years of shambolic waterfall development and ever-changing requirements.
Re: (Score:2)
If you had changing requirements, you weren't doing waterfall. Sorry.
Re: (Score:2)
In the past when you did it sloppy, you'd get called out on it
I have been in tech for 30+ years, and I have seen no evidence whatsoever that sys admins were less sloppy in the past, nor do I believe that management was better at "calling them out" when they made mistakes. Backups and reliability in particular are way better today.
Every generation tends to believe that young'ins are dumber and lazier than they were. They are usually wrong.
Re: (Score:3)
I have to disagree here a bit. Not with the idea of doing backups -- everyone should -- but that's looking at the half problem the wrong way. It's the right solution for customer data, but not for all the code and other materials that make your web site happen.
I've seen this problem a lot: all the work product that makes a web presence happen gets done on the hosted server. That's beyond stupid - that's failing to even understand your job.
All the work that goes into your hosted web site -- your store, you
Re: (Score:2)
Offsite, tape backups aren't even really all that necessary. You just need any backup that you can't use one command in the system to delete all of your data.
You could use AWS S3, and just use something like Glacier to back up your data. Since it takes like 4 hours for it to be rotated back into being online, you have about the same effect.
Also, while offsite backups are useful, for a host with 1,535 customers, who are all making changes, even if you have a daily offsite tape backup, you could find yourse
Re: (Score:3)
Minimums:
3 Copies
2 Locations
2 Formats
2 Mediums
Copies, two local, one remote
Locations, geographically distinct
Formats Natural, Raw, compress etc
Mediums, SATA, USB, Tape, SAN manufacturer etc.
By Minimum I mean bare minimum. the reality is, there should be cascading copies being made, and Long Term Arching able to restore to a set point in time. For Copies you'll need at least three, more likely more version (date specific). You should separate your copies geographically so that when California gets the big on
Re:Three words (Score:5, Funny)
Offsite, offline BACKUPS
Would not have helped in this situation. His typo resulted in this command:
"rm -rf --no-preserve-root --write-zeroes --shred-mbr --exec-all-ssh-hosts --douse-hydrofluoric --high-velocity-eject-removable-media --carpet-bomb-offsite-backup --salt-earth"
Which, I mean, who hasn't accidentally done that? The keys are like right next to each other.
Re:Three words (Score:5, Funny)
Re: (Score:3)
Offsite, offline BACKUPS
Would not have helped in this situation. His typo resulted in this command: "rm -rf --no-preserve-root --write-zeroes --shred-mbr --exec-all-ssh-hosts --douse-hydrofluoric --high-velocity-eject-removable-media --carpet-bomb-offsite-backup --salt-earth" Which, I mean, who hasn't accidentally done that? The keys are like right next to each other.
Man, I haven't laughed out loud like that in a long time. Thank you for that.
Re: (Score:2)
Make them Redundant backups too? Good idea.
Re: (Score:2)
Four words: filesystem with automatic snapshots.
I've never admined a major customer linux installation myself, but as a developer I've been called into rescue customers who messed up their databases, and let me tell you being able to root through the transaction log and undo mistakes like "delete * from foo where conditionThatIsAlwaysTrue" is a lifesaver. Oracle, which is a company I despise for a number of reasons, does a really good job of that.
The rule for production systems should be "never work withou
Re: (Score:2)
He capitalized the wrong word. BACKUPS instead of OFFLINE
Re: (Score:2)
I tried offline backups once, but I couldn't figure out how to get the data off my computer and on the backup without first putting the backup online.
Re: (Score:2)
It's true, if you have only one offline backup there are short periods of total risk involved. If you have more than one offline backup though, you just do one at a time and there's never any window of time when all your backups could be taken out by a lightning strike/malware/hilarious accidental deletion.
With newer versions of rm you can also use --preserve-root to prevent this sort of thing from happening.
Re: Three words (Score:5, Informative)
Addendum - just checked a CentOS server, and rm --help says that --preserve-root is enabled by default, and has to be overridden with --no-preserve-root.
Three steps (Score:3)
Put backup copies in truck.
Drive them to the backup site.
Repeat regularly.
Re: (Score:3)
... and don't underestimate the bandwidth.
Re: (Score:3)
Re: (Score:2)
no, asteroid or nuclear blast. safest would be dig a deep dark hole, and send it down with a guys and pack mules... as well as the 2 trucks going opposite directions.
duh.
Re:Three words (Score:5, Informative)
Because he is a retard.
All servers got deleted and the offsite backups too because the remote storage was mounted just before by the same script
Clearly a case of a fool thinking that a sync (copying data to another place regularly) is a backup. It's not a backup if you can easily copy corrupted data to your only copy. Or, in this case, if you can easily delete the data from your "backup" copy.
rsnap is popular. Should pull from read-only accou (Score:5, Insightful)
Rsnap is a very popular backup system which uses network mounted drive as it's default/most common configuration. I constantly remind people on the rsnap mailing list about the existence of cryptolocker type malware.
A much safer way to do it is to have the backup system PULL backups using a read-only account. That way no command on the live system can touch the backups, and the backup system can't change anything on the live system - either accidentally or maliciously.
One solid backup / hot spare system that does it safely by default is Clonebox.
Re: (Score:3)
The best of all worlds is pull based backup software. However, the enterprise based programs are extremely pricy, well out of the range for a home user. The cheapest around would probably be Windows Fundamentals which is a descendant of Windows Home Server.
What I've wound up doing on a small scale (this won't scale up past a few machines) is having a hardware NAS appliance. It had a samba share and account for every machine. The Windows boxes use Veeam to dump their data onto the individual shares. Eve
Re: (Score:2)
Three MORE words:
Teh Burning Stoopid . . .
--no-preserve-root (Score:5, Informative)
Re: (Score:2)
Wasn't he trolling? (Score:5, Insightful)
Re:Wasn't he trolling? (Score:5, Interesting)
My operating theory is that the guy is constructing an alibi. Perhaps he has gotten wind of an investigation and wants to look like a hapless idiot and not someone engaged in destroying evidence.
Re: (Score:3)
You missed one.
-- Some anonymous coward complains about people calling out trolling, trolling.
The funny part is the person you responded to did not claim "trolling", they expressed a healthy skepticism. That last part is something more people should have. There are plenty of liars out there. Quite often they work for main stream media outlets and hold public offices.
Re: (Score:2)
Re: (Score:2)
I don't like windows, but LOVE PowerCLI for managing VMware environments. And HATE using pyvmoni.
I get to troll everyone.
Re: (Score:3)
It was a pretty obvious troll if you read the whole thread:
1. The guy claims to have made the most insanely improbable mistake to kill his entire set of servers. Possible, but unlikely. Most took the bait on this one.
2. He had no explanation as to why "--no-preserve-root" didn't save him - basically looked like he didn't know about it, and he was lying.
3. later on he responded to someone's suggestion to use dd to backup saying he reversed if and of - which is probably the second most joked about UNIX sysa
Re: (Score:2)
Re: (Score:2)
Meh (Score:3)
This is borderline bait at this point.
Can this example finally serve as a textbook example of why you need to make offsite backups that are physically removed from the systems you're archiving?
There are plenty of examples already and keeping a set of backups physically disconnected from running infrastructure is pretty well established practice, with random software bugs and screw ups being just one of many reasons. That said people will continue to have all their backups fully accessible (and destroyable) or just not back things up at all and things like this will continue to happen.
Guy can possibly recover the data, but the company is probably still screwed reputation wise.
Re: (Score:2)
There are plenty of examples already and keeping a set of backups physically disconnected from running infrastructure is pretty well established practice
This seems to be more of a case for multiple backups instead of online vs offline backups. The way I read the summary it looks like the bug occurred after mounting the backup which could happen in any poorly coded scenario regardless of how secure you leave your offline backups.
Re: (Score:2)
Right, at minimum there should be two sets, and both should never be connected at the same time for exactly this kinda reason.
Re: (Score:2)
There are plenty of examples already and keeping a set of backups physically disconnected from running infrastructure is pretty well established practice
Pixar circa ToyStory 2 springs to mind.
https://www.techdirt.com/artic... [techdirt.com]
Empathy (Score:5, Funny)
I have that cold feeling in my stomach just reading this summary. ick.
I did something similar (though not quite so destructive) nearly 20 years ago when I was first learning Linux.
I my case I was trying to get rid of all the hidden files in root's (/root) home dir using 'rm -rf .*'
Guess what that did?
Yeah, that wasn't a highlight of my career...
Re: (Score:2)
Same here. Thought I was in /tmp, was actually in /, and did an "rm -rf *".
Fortunately, things were a bit slower back then and glob ordering being what it is I was able to ctrl-C it before it got further than /bin. With rcp being in /usr/bin/, I was able to (carefully) recover from another system.
Re: (Score:2)
I also did that years ago on a Sun 1 system, only got part way through /bin. Recovered the contents of /bin from a release tape. Learned to be a bit careful after that.
Re: (Score:2)
My turn.
I was extracted a tarball into my home directory. I was done with it and the contents in my home directory and wanted to remove them. Knowing a tarball of foobar.tar.gz typically extracts to ./foobar, I typed:
rm foo[TAB]* -rf
I expected bash to fill in to the . in foobar.tar.gz, instead, somehow I hit a space between [TAB] and *, executing the command: rm foobar * /rf on my entire home directory (meant to execute rm foobar* -rf). And this was before I knew how to do data recovery.
Similar misu
Re: (Score:2)
Well, I have good news and bad news. The good news is that I've removed all of the hidden files.
Re: Empathy (Score:2)
They were available but, there was no commands or binaries to manipulate them supplied. They still don't have those commands; you have to use 3rd party tools.
Re: (Score:2)
Try `ls .*`. You'll find that "." matches, but more importantly, ".." matches too. So, if you have the rights on the parent directory, `rm.rf .*` == `rm -rf ..` .*` works just fine for non-directories, but you need to take care of directories separately. .[A-Za-z_0-9]*` will likely do the job, but if you've funny characters in second position, delete them specifically afterwards.
`rm -f
`rm -rf
Fun thing about TRIM (Score:5, Informative)
While this guy was most likely using traditional HDDs where block level recovery is a possibility, for those of you using SSDs that have TRIM properly enabled, don't expect to be able to recover deleted files from the same drive unless you are really really fast.
TRIM automatically zeros the blocks of deleted files and they are GONE aside from vague sci-fi and probably nonexistent NSA-type forensics.
Re:Fun thing about TRIM (Score:5, Informative)
Without trim the ssd has to preserve the entire logical block device its emulating, ie if you have a 64GB drive then even if it only has 4KB of "files" on it, the device still has to preserve all 64GB because it doesnt even know what a file is, let alone that you deleted one.
With trim the ssd only has to preserve what the OS told it was important to preserve. So instead of preserving 64GB if data it only has to preserve your 4KB of data. Trim marks logical sectors as dont-preserve.
What the SSD will not do is overwrite trimmed physical sectors just because they were trimmed. In fact, that data could linger there for years even with a high amount of read/write activity because SSD's only erases entire physical blocks, not just the subsectors within blocks that were trimmed.
So recovering is not sci-fi. Recovery is a fact. What can't be done is recovering the data via commands that target the logical rather than physical device.
Re: (Score:2)
That would be a real problem. SSDs don't typically provide low level access or documentation.
Further, oddly enough, rm -rf would result in a lot of writes as metadata is updated.
Re: (Score:2)
That would be a real problem. SSDs don't typically provide low level access or documentation
Maybe not to you, but to the NSA or people with a court order - and the SSD removed from the system and cracked open - many things are possible.
Re: (Score:2)
If the OS needs to TRIM an entire RAID stripe, it fires off a TRIM command to the data drives, and calculates parity for null data, and writes that to the parity drive.
1500+ customers and he can't afford (Score:2)
a couple cheap Kimsufi servers from OVH for remote backup in EU and In Canada?
Re: (Score:2)
Read the article. He claimed to have off-site backups in other countries, but they were mounted.
But also read the note under the summary. This whole story is probably bullshit.
Re: (Score:2)
It probably is bullshit. Who fucking mounts servers in another country to do the backups to directly?
You archive and compress that shit locally and then move it to the remote server. That prevents your daily backup from taking 48 hours to complete and helps considerably on those data transfer charges.
Having a simple archive and transfer via FTP or something alone could have prevented him from deleting the remotes with one command. I have trouble believing he set up a NFS or other remote volume to another
insurance fraud at best (Score:2, Interesting)
This has such a smell of BS around it. given the fact that backups are indeed offsite and that a company has more the 1 server etc.etc. Even my own simple setup consisting of a pc, laptop, tablet, qnap and some external HDD and sticks is impossible to delete with 1 script. total bollocks.
Wonder if he found incriminating material or has gambling debts, far more plausible
manishs (Score:5, Insightful)
Re:manishs (Score:4, Funny)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re:manishs (Score:5, Informative)
Re: (Score:3)
2 Big issues (Score:2)
Why in hell is is running scripts out of ansible? Why are those scripts not running on a QA system thats a block for block clone of production? Finally what idiot thinks that some mounted drives he copies stuff for is a backup system?
Tape disk I do not care just treat disk as tape, plenty of backup system are more than happy to do just that. Rsync is not nor will it ever be a backup, snapshots are not a backup, some script some guy wrote that works ok is not a backup. Now they can all help to meet your
Re: (Score:2)
man sync
[...]
-b, --backup
With this option, preexisting destination files are renamed as each file is transferred or deleted. You can control where the backup file goes and what (if any) suffix gets appended using the
--backup-dir and --suffix options.
Re: (Score:2)
Err, please read 'man rsync' of course :-)
I also used the rsync batch mode to keep the last 6 months daily backup.
Re: (Score:2)
That's still not a real backup strategy. Look all my backups are on mounted disks/arrays. It's great for RTO and can be part of one but at the end of the day you still need to get that data offline and offsite. So it might be more correct that rysnc is not a complete backup system.
I've been down that road to many times it's far far too prevalent in the hosting and small business segments that think a single copy will be fine. Idiocy like a backup drive in a local system, because that shares no failure
What happened to NEWS for Nerds? (Score:2, Insightful)
This was a blatant troll on a forum and now because some idiot millennial wrote an op-ed piece, some idiot (manishs) put it on the /. frontpage?
Are the admins now supporting the things the moderation system fights on their own site?
This story is more of an embarrassment than the political vomit I've had to endure because _this_ story doesn't even qualify as news. e.g. What Company did he destroy exactly? You would think the incredibly obvious lack of facts would be a tipoff to someone.
Re: (Score:3)
It's not millennials who have excessive smugness, outrageous senses of entitlement, unjustifiable arrogance, and penchants for causing lots of problems for others. It's young people. Since millennials are currently young, they get all the blame. In twenty or thirty years, the millennials are going to be saying this about the currently young generation.
Re: What happened to NEWS for Nerds? (Score:5, Insightful)
I make it a point to lump people into the category of "everyone". Then I can despise them all equally without picking and choosing favorites.
Hobbling the default rm command, etc. (Score:2)
Hobbling the default rm command slightly would make a sense, possibly having a second command (oblit or something) for the really nasty stuff, would make sense. Many commands can be unnecessarily destructive, and those destructive commands are too easy to invoke by accident. Possibly requiring a --really and a --reallyreally switch on rm to enable things like rm -rf crossing filesystems, would make sense. I did once make a quick hack so that rm -rf would require an environment variable to be set in order to
Not everything (Score:2)
When an friend an I got started with Linux he wanted to remove his Slackware install from a dual boot PC. For fun he ran rm -rf / on that install. We had a good laugh when the message scrolled by of the OS trying and failing to remove files from the CDROM. That was until he realized that he had mounted his Windows partition too. It didn't fail to remove files there :-)
Something similar (Score:2)
I was working at a small development shop about 15 years ago and I came in one morning to find the main development server not working. Turned out that the previous night a developer on the other project ran "rm -rf" from the root directory on the Sun box and then tried to fix things before giving up and going home. No note, no call to the boss, nothing to indicate what had happened so I had to figure that out when I arrived around 8 AM. Oh, and no backups of their project. I at least had the latest versi
He just did a "rm -rf My_IT_Career" (Score:2)
Still value as a troll (Score:5, Insightful)
I collect these stories for people who I mentor. Even if they're trolls, they work as cautionary tales, because lots of people have had similar smaller scale disasters (as evidenced by posts in this thread) and it's healthy for mentees to get a taste of what can happen when you (for example) forget to error check your script parameters.
In a big way it doesn't matter if it's true or not, it could be true which makes it a teachable moment. I'm sure everyone who reads the story will run a mental checklist to see if they have a script somewhere that could EVER do it. Do they have their backups mounted when they should be rsyncing, etc.
Min
Backup with rsync instead of a mount (Score:2)
That's so simple and effective, work on local network as well as on remote networks thank's to ssh.
Corrections (Score:4, Insightful)
Man ALLOWS his entire company to be wiped out in one command.
Man DESIGNS his entire company to be wiped out in one command.
Man SETS UP his entire company to be wiped out in one command.
Hint: I work in schools. Once I had a teacher delete their entire planning folder. Then (and DO NOT ask me why, because I don't understand it either), they emptied that folder from Recycle Bin. They rang up in the more embarrassed panic.
And then it was explained that we still had copies of that folder in:
a) Shadow Copies of the profile on the client.
b) Network Copies of the profile that they were logged in as (and which fortunately hadn't logged off once they realised what they did).
c) Shadow Copies of the profile folder on the server.
d) Copies of the profile folder on all the other servers.
e) Copies of all the servers on replica servers.
f) Copies of the server VM's and storage in a primary backup location.
g) Copies of the server VM's and storage in a secondary backup location.
h) Copies of the server VM's and storage in a tertiary backup location.
i) Several off-line and off-site copies of the server VM's and storage .
k) Random, casual backups all over the place.
And that's just for the crap that teachers think is important (i.e. a lesson plan they have to write every two weeks and which they can't re-use anyway).
Fuck knows what this guy was thinking, but there's no one one command ANYWHERE should be able to do that many actions, let alone dangerous actions that you haven't evaluated properly. Honestly, some of those machines don't even TURN ON until the backup window, and even the backup devices have rollback and shadow-copy-like functionality on top of whatever the backup software gives (incrementals, etc.). And several are DELIBERATELY offline for almost their entire lives and have entirely disparate credentials so no one command could ever affect them.
Not being funny, but we're talking a small school of 400 5-14 year olds here. He actually has more customers than I have users. And you just can't fuck about like that, so if he thinks he can, I honestly have zero sympathy and can only laugh.
Extremely timely article! (Score:3)
I just got put on a project at work as "the systems guy" for a project being built in Azure. This is in support of a reasonably critical system, and the development staff are salivating over the chance to self-deploy code and infrastructure. It sounds like this problem was caused by the first thing I noticed as a risk -- if you don't limit what Azure users can do, it's just like giving them the keys to the data center. And this isn't in an "evil BOFH control freak" sense, this is just the fact that everything in Azure is virtual and easily changed either manually or through automation. So, someone who's having a bad day could easily make a mistake and get rid of things they have permissions on -- it's possible in AWS too.
It's a really different mindset than even a hosted IaaS service. There, if you do something stupid, at least the physical infrastructure doesn't get rolled up and carried off. Now hopefully you have backups if that happens and can just restore the VMs and storage as needed, but if developers are running the show I would highly doubt it. (In Marco's case, I would imagine this was caused by the classic "run as root, because I'm the boss" issue.
So, in summary, all the (good) sysadmins worrying about the cloud taking their jobs need not worry. The rules of designing a safe computing environment have changed, but they haven't gone away entirely! I'd be a little worried if I were a savant-level EMC or Cisco guru right about now, but generalists with good heads on their shoulders are still in demand.
Not buying this (Score:2)
No line of bad code (Score:2)
Can you spell "test"?
Re: (Score:2)
Can you spell "test"?
Can you use it in a sentence please? Oh wait no never mind. I think I've got it! D-O-I-T-L-I-V-E???
...and...?? (Score:3)
He admitted it publicly?
Perhaps time for a change to rm (Score:2)
In this case, change rm to NOT allow
With this minor change, it could save noobs from themselves and would like not be used that often in the first place.
Chain of Mistakes (Score:4, Informative)
Theology Lesson (Score:2)
On a Linux system, root is God(*)
God is omniscient, omnipresent, and infallible.
Therefore, when root deletes files, it's never a mistake, and the files should be immediately destroyed forever without question.
(*) Unlike those heathen Windows systems, where there can be multiple gods, some of whom are more equal than others... and not necessarily in ways that are obvious to casual observers... ;-)
Old Saying (Score:5, Interesting)
"To err is human. To really fuck things up, you need a computer."
I prefer that any bulk or query-based "delete" command ask for confirmation along with basic feedback. Example pseudo-code:
> delete *:*.*
You are about to delete 832 folders and 28,435 files.
Your choices are:
1 - Proceed with deletion
2 - List path details about the above folders and files
3 - Cancel deletion
Your Choice: __
(end of example)
It may be slower and/or more resource intensive, but that's better than mass boo-boo's.
An optional command parameter could switch off verification, but verification should be the default. This is something Unix/Linux gets backward in my opinion: the default should be confirmation mode, not the other way around. In other words, a command switch should be required to switch off confirmation rather than requiring a command switch to turn confirmation on.
Typical SQL doesn't have a confirmation mode, so I usually do a verification query on the WHERE clause before running the actual:
-- check
SELECT count(*) FROM myTable
WHERE x > 7 AND foo='BAR'
-- actual, keeping same where-clause
DELETE FROM myTable
WHERE x > 7 AND foo='BAR'
I also often inspect at least some of the actual rows, not just the count. Thus, as a rule of thumb, do random spot-checks of actual data, and a total count before final command execution.
Re: (Score:3)
"This is something Unix/Linux gets backward in my opinion: the default should be confirmation mode, not the other way around."
1. All Ubuntu versions and derivatives (and I think Centos/RHEL as well) alias rm to "rm -i" out of the box. Drives me crazy; with every install I have to hunt down whether those aliases were defined in .profile, .bash_profile, .bashrc, /etc/profile, /etc/bashrc, or somewhere in /etc/bash/*.
2. Command-line tools that ask for confirmation suck for scripting. Especially if those prompt
Re: (Score:2)
He can boot on a CD or USB and recover most files.
Re: (Score:2)
That will work unless the drive was on an SSD and the OS told the drive to TRIM the deleted blocks.
Re: (Score:2)
Re: (Score:2)
Adding to AC's astute observation: ..."In the cloud" does not mean "Is backed up." ...'Deleted' from the cloud does not always mean 'deleted'. ;)
Re: (Score:3)
For most users the cloud is more reliable and more accessible than anything they'll ever be able to do in a SO/HO environment.
The problem is that medium sized (1000+ employees) seem to think this too.
And then have no backups, version control or anything else because some PHB said 'put it in the cloud, and stop arguing with me.' to the IT engineers who wanted local & remote backups, version controls, redundancy of hardware, network and power, etc, etc, etc.
Re: (Score:2)
Front page exposure always results in a Slashdotting. Oh, wait. Never mind.
Re: (Score:2)