Live data from Hacker News

Moved ~/.local/share/steam. Ran steam. It deleted everything owned by user

github.com

191–200 of 280 posts

Re: Moved ~/.local/share/steam. Ran steam. It deleted everything owned by user

#191

Earlier quoted context omitted.

Sandboxed applications in OS X can read/write to arbitrary locations if they use the system Open/Save dialogs to ask the user about those files (after opting into sandboxing, of course). See here [1]. For files and folders the user cares and knows about (documents, projects, etc), this shouldn't be a problem. For files the user doesn't care about (caches, configuration), you can just leave them in your sandboxed cont…

Lots of applications (like Emacs and vim) don't use the system file dialogs though. It'd be nice to preserve old-fashioned file access for them.

But these are applications for knowledgeable users I think which is not the type of users the GGP is talking about. For these it might be ok to ask for permission. Or to grant it automatically if you are root or sudo'ed. And many use cases could get around with allowing silently to write if the file has been previously been opened by the same application.

Re: Moved ~/.local/share/steam. Ran steam. It deleted everything owned by user

#192

Many of the comments mentioned this should have been caught in the code review. I suspect they don't perform code reviews. Makes me wonder, is there a tool, system, service for auditing how many 'pair of eyes' have reviewed a given line of code. This would be hard to determine, but could be useful. I am envisioning a heatmap bar or overlay that indicates the number of reviews a line of code has received.

>I suspect they don't perform code reviews.

It certainly seems that way. CSGO (their FPS) is notorious for updates that break things, like very recently a gun having less ammo than it should, or masks (halloween thing, I think) being rendered through smoke (a crucial feature of the game).

Re: Moved ~/.local/share/steam. Ran steam. It deleted everything owned by user

#193
post #3

Here's the offending shell script code: # figure out the absolute path to the script being run a bit # non-obvious, the ${0%/*} pulls the path out of $0, cd's into the # specified directory, then uses $PWD to figure out where that # directory lives - and all this in a subshell, so we don't affect # $PWD STEAMROOT="$(cd "${0%/*}" && echo $PWD)" [...] # Scary! rm -rf "$STEAMROOT/"* The programmer knew the danger and di…

Whenever I write something scary like that, I usually wrap it in a function, double checking if it's really the folder you wish to delete ... Often even adding a user-verification if possible.

Re: Moved ~/.local/share/steam. Ran steam. It deleted everything owned by user

#194
Well I'm on the guy's side but this worth noting:

Including my 3tb external drive I back everything up to that was mounted under /media.

Well maybe it was just unfortunate and the drive just happened to be mounted or the "backup" is always online. If it is the latter it is a really bad idea. If your computer is compromised you risk all of your backup. A proper backup should protect your data from these occasions.

Re: Moved ~/.local/share/steam. Ran steam. It deleted everything owned by user

#195

To those name-calling the author of the script: The product/update is hyped and the release date is set in stone. Tensions are high and your boss has already let you know that you're on thin ice and not delivering on the project goals. A last-minute showstopper bug comes in, caused by file leaks. Everyone is scrambling, and the file belongs to you so its on you to fix it alone. There is no time for code review, and d…

So I guess it's a choice between getting fired for not meeting a deadline, and getting fired for destroying customer data. I'd rather take the first option. At least my reputation will still be somewhat intact. And as a bonus, I can get out of that hostile environment earlier.

The choice is between definitely getting fired and maybe someone's data getting deleted.

Re: Moved ~/.local/share/steam. Ran steam. It deleted everything owned by user

#196
post #149
post #140

Earlier quoted context omitted.

The "rm -i" alias is a horrible, horrible idea. Red Hat has a lot of stupid defaults, but this is probably the most questionable one. The useless confirmations on every deletion is so intrusive that people will instinctively try to work around it. In the best case they'll undefine those crappy aliases in their own shell config, or maybe gravitate toward writing /bin/rm rather than rm to avoid the alias expansion. In…

Hmm. Well I guess it's just me then. I've been burned so many times by rm/mv/cp that I actually do always read their confirmations and give it a 2nd thought. I rarely delete files unless it's a mass delete or files & folders that I do "rm -rf". and I pretty much never intend for mv or cp to overwrite an existing file.

zsh has a nice feature where rm is only interactive if you are deleting everything in a folder. Another safety feature I really like in zsh is to tab-expand wildcards, so I can check that it's not deleting anything it shouldn't.

Re: Moved ~/.local/share/steam. Ran steam. It deleted everything owned by user

#197
post #192

Many of the comments mentioned this should have been caught in the code review. I suspect they don't perform code reviews. Makes me wonder, is there a tool, system, service for auditing how many 'pair of eyes' have reviewed a given line of code. This would be hard to determine, but could be useful. I am envisioning a heatmap bar or overlay that indicates the number of reviews a line of code has received.

>I suspect they don't perform code reviews. It certainly seems that way. CSGO (their FPS) is notorious for updates that break things, like very recently a gun having less ammo than it should, or masks (halloween thing, I think) being rendered through smoke (a crucial feature of the game).

That's not a lack of code review, that's a lack of QA.

Re: Moved ~/.local/share/steam. Ran steam. It deleted everything owned by user

#198
post #189
post #21

Earlier quoted context omitted.

Gotta question why they used -f.

That's normal, but why the trailing slash?! That's just pointless, and almost looks like an explicit deathtrap. Without the slash, an empty variable would result in a command line of "rf -rf" which would simply fail due to the missing argument. There is absolutely no need for having a trailing slash, it's not as if "rf -rf foo" and "rm -rf foo/" can ever mean two different things, there can be only one "foo" in the f…

> it's not as if "rf -rf foo" and "rm -rf foo/" can ever mean two different things

That's true, but the original code was akin "rm -rf foo/*" and that's different, since it removes the content of the directory while preserving it.

Re: Moved ~/.local/share/steam. Ran steam. It deleted everything owned by user

#199
Just wanted to remind everyone that deleted files can be recovered until their space is reclaimed for something else.

So if you notice something like this happening, shut down computer asap, so they can't be overwritten. Plug drive into another computer but do not mount it. Instead run some file recovery program on it.

For an SSD it becomes murkier though, what with their trimming and automatic garbage collection.

Re: Moved ~/.local/share/steam. Ran steam. It deleted everything owned by user

#200

rm -rf "$STEAMROOT/"* This is why serious bash scripts use set -u # trap uses of unset variables Won't help with deliberately blank ones, of course. Scripting languages in which all variables are defined if you so much as breathe their names are such a scourge ... I did this once in a build script. It wiped out all of /usr/lib. Of course, it was running as root! That machine was saved by a sysadmin who had a similar…

While you're at it: set -e # exit on unchecked failure That way you don't trudge forward through an untested code path after a failure, you stop there and then.

I use this holy trinity in most of my scripts:

set -o nounset # set -u

set -o errexit # set -e

set -o pipefail # I'm not sure this has a short form.

I use the long forms for the option names because they're self documenting.

If anyone has more suggestions, I'm all ears.

Post reply on HN