Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ooops.

github.com

Post reply on HN
Print view View original

121–130 of 247 posts

Re: Ooops.

#121

Post by trafficlight »

DrPhish wrote: post #115
samstokes wrote: post #97

Earlier quoted context omitted.

The habit I learned was: before running any DELETE or UPDATE statement, run a SELECT with the same WHERE. (e.g. if I meant to say DELETE FROM puppies WHERE cute = 0, first run SELECT FROM puppies WHERE cute = 0.) I find I remember to do that because of the direct benefit (getting a sneak preview of what I'm going to delete), but it also means I end up thinking twice about the WHERE statement, so I'm much less likely…

I'm a couple of levels more paranoid than that. First, I'll write the DELETE as a regular SELECT (to preview number of rows), then turn it into a SELECT INTO to save the soon-to-be-deleted rows into a table with a backup_date_ prefix (So old backups can be deleted occasionally). Next, before changing anything, I wrap the statement in a BEGIN TRAN, and ROLLBACK TRAN. After all that, I will finally modify the SELECT IN…

Possibly overkill. But at least there won't be any tears.

Re: Ooops.

#122

Post by DenisM »

trafficlight wrote: post #76
srean wrote: post #46

I learned a rather unusual trick to keep myself safe from unintended glob matches. It is not "fool"-proof, but it will probably dilute an unmitigated disaster into an incomplete disaster: Keep a file named -i in the sensitive directories. When glob picks it up, which should be fairly early, it will be treated like a command line argument. Has saved me on occasions. I also had a friend in school who used to, for whate…

I hate that feeling you get in the pit of your stomach after you realize what's happening. Same thing when you forget the WHERE on a DELETE FROM.

  BEGIN TRAN
  DELETE FROM ...
  SELECT FROM ...
  ROLLBACK TRAN -- things look bad, itchy finger, etc
  COMMIT TRAN -- things look good, skip previous line
That, and I have 15-minute backups for all databases I care about.

Re: Ooops.

#123

Post by trustfundbaby »

tta wrote: post #80
trustfundbaby wrote: post #74

Earlier quoted context omitted.

dead tired, 4am in the morning working on a client app for a huge client of theirs (I was subcontracting) was trying to remove everything inside a folder and instead of going rm -rf ./* I went rm -rf . (can't get the wildcard thingamajig to show up) It took me a second to understand why the command was taking so long to run, by the time I figured it out and killed the command, I had wiped out almost half of what was…

Wouldn't that just delete the folder instead of emptying it?

I can't get the wildcard character to show up ... it should be x.x

Re: Ooops.

#124

Post by meastham »

cool-RR wrote: post #90
meastham wrote: post #88

Earlier quoted context omitted.

Almost all of the desktop environments commonly used with Linux do have a trash bin.

If it wasn't obvious, "Why is `rm -rf` not connected to the recycle bin?" is implicit in my original question.

Because that's not what rm does. Changing it would be breaking all sorts of standards. Many, many things depend on rm simply unlinking files. Why don't you use a different program if you would like to have some sort of trashbin behavior?

Re: Ooops.

#125

Post by DenisM »

You get in trouble not at the moment this happens, you get in trouble much earlier than that - when you allow yourself into a situation where a single typo leads to ruin.

Myself, I use TimeMachine and bitbucket on my Mac, and every-15-minutes snapshots on all Amazon EC2 EBS volumes. Similar solutions can certainly be found for your platform of choice.

Re: Ooops.

#126

Post by evilduck »

cool-RR wrote: post #114
uxp wrote: post #109

Earlier quoted context omitted.

I would speculate that it is a historical reason. It's no secret that the Unix environment was not designed for personal use in homes, but on mainframe time shared computers inside universities and businesses. Space was limited, and just moving files to another location to deal with later added unnecessary steps to a process that didn't have much of a benefit, at the time. As space has become less valuable on compute…

there is no need to recreate the functionality at a lower level. I refer you to the original submission.

Care to provide any example of an OS that would prevent this? Windows and OSX both have this same fault.

Re: Ooops.

#127

Post by r00fus »

trafficlight wrote: post #76
srean wrote: post #46

I learned a rather unusual trick to keep myself safe from unintended glob matches. It is not "fool"-proof, but it will probably dilute an unmitigated disaster into an incomplete disaster: Keep a file named -i in the sensitive directories. When glob picks it up, which should be fairly early, it will be treated like a command line argument. Has saved me on occasions. I also had a friend in school who used to, for whate…

I hate that feeling you get in the pit of your stomach after you realize what's happening. Same thing when you forget the WHERE on a DELETE FROM.

DELETE FROM? Try TRUNCATE TABLE CUSTOMER ... that one skips the transaction log too, no ROLLBACK possible.

Re: Ooops.

#128

Post by cool-RR »

meastham wrote: post #124
cool-RR wrote: post #90

Earlier quoted context omitted.

If it wasn't obvious, "Why is `rm -rf` not connected to the recycle bin?" is implicit in my original question.

Because that's not what rm does. Changing it would be breaking all sorts of standards. Many, many things depend on rm simply unlinking files. Why don't you use a different program if you would like to have some sort of trashbin behavior?

I'd be cool with using a clone of `rm` that sends to the recycling bin instead of actually deleting. I think that Linux should include a clone like this by default.

Re: Ooops.

#129

Post by cool-RR »

rcfox wrote: post #119
cool-RR wrote: post #108

Earlier quoted context omitted.

You don't want to have to depend on the user to clean up after your automation. I don't see what's the big deal is. Once in a while when the recycling bin gets too big, the user can empty it. Or you can have a scheduled operation that deletes stuff after 30 days.

> Once in a while when the recycling bin gets too big, the user can empty it. Many Linux systems don't even have a regular "user". They just sit in a corner and serve webpages, or do other tasks silently. > Or you can have a scheduled operation that deletes stuff after 30 days. Why not just keep backups for 30 days?

Why not just keep backups for 30 days?

Be realistic. Setting up backups takes effort that many users are not going to expand, while the recycling bin mechanism can be set up by default.

Re: Ooops.

#130

Post by cool-RR »

evilduck wrote: post #126
cool-RR wrote: post #114

Earlier quoted context omitted.

there is no need to recreate the functionality at a lower level. I refer you to the original submission.

Care to provide any example of an OS that would prevent this? Windows and OSX both have this same fault.

I don't have an example, I'm just thinking what's the best way for an OS to handle deletion.
Post reply on HN