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

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

github.com

Post reply on HN
Print view View original

231–240 of 280 posts

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

#231

Post by skrebbel »

dingaling wrote: post #188
preconsider wrote: post #90

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…

> Tensions are high and your boss has already let you know that you're on thin ice and not delivering on the project goals. Valve doesn't have bosses, remember?

Except of course they actually do. It'll just take you half a year to figure out who they are.

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

#232

Post by anon4 »

rwallace wrote: post #222
Chris_Newton wrote: post #51

This seems like yet another good example of why robust application-level access control would be a helpful thing to build into modern operating systems, in addition to the typical user-based controls. This may have been both a rookie mistake and a regrettable failure of code review processes, but in any case it simply shouldn’t be possible for an application running on a modern system to wipe out all user data withou…

As a more immediate fix with less collateral damage, since Unix programmers refuse to stop putting `rm -rf` commands in shell scripts (they seem to think the suggestion is an insult to their manhood), change the behavior of rm so that by default it either disregards -rf or moves the target files to a trash directory where they can be retrieved in the event of an error.

Already exists - libtrash.

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

#233

Post by jjnoakes »

Zancarius wrote: post #103
pjc50 wrote: post #31

For those of you worried about important files, chattr +i is a useful defence. No easy way of applying this automatically. Long ago I had a kernel hack that would kill any process that attempted to delete a canary file. Worked OK but no chance of it ever going mainstream.

Reminds me of a shell trick I saw many years ago for short circuiting accidental 'rm -rf's by issuing a 'touch -- -i' in a sensitive location. In bash (and others), the glob operator inadvertently feeds the '-i' (now a file) into rm as an argument which then interprets it as its "interactive" flag, causing it to prompt for continued removal.

Which only helps "rm -rf ". It does nothing for "rm -rf /anything" or "rm -rf /anything/" or "rm -rf /*" or any other way of spelling doom.

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

#234

Post by jjnoakes »

colanderman wrote: post #45
jjnoakes wrote: post #33

Earlier quoted context omitted.

There's nothing wrong with that line as long as you know "$STEAMROOT" contains a directory that you wish to nuke. The issue is that this particular script did not set up $STEAMROOT correctly.

The thing is, there are so many ways for STEAMROOT not to be set correctly in Bash. Just one typo in some future edit can bork everything if it's not tested thoroughly. Sure, you could somehow check that STEAMROOT is set to something resembling what you want to delete. But manifests are much more simple to get right. EDIT: Alternatively , pick a well-known UUID, and put everything under a directory with that name und…

If you can't write a shell script without being sure your variables are set, then don't write it in shell.

A MANIFEST is not the right answer. Steam deals with any number of third-party games which may drop any number of files into these directories.

The best way to nuke a directory is 'rm -rf "$DIRECTORY"'. Any amount of "well what if $DIRECTORY points to the wrong place" has nothing to do with the removal operation itself.

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

#235

Post by sudioStudio64 »

preconsider wrote: post #90

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…

People on an Internet forum will always be smarter and more professional than anyone actually doing something for a living.

I doubt, though, that this person will ever make that mistake again.

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

#236

Post by quotemstr »

chopin wrote: post #191
quotemstr wrote: post #162

Earlier quoted context omitted.

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.

I will not use a system that pops up some kind of UAC-like approval dialog for every call Emacs makes to open(2).

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

#237

Post by hobs »

vertex-four wrote: post #220
mercurial wrote: post #208

Earlier quoted context omitted.

Doesn't it have an API? It could mandate that "random files" should only be created and deleted via the API, and update the manifest accordingly. Put the game in a read-only folder to make sure it happens.

Steam actually sells a number of games which haven't been modified for use with Steam at all - no DRM integration, no achievements. Further to that, it sells games which use closed engines that are never going to be modified to use Steam's APIs to do things.

Or worse, basically just glorified installers for games for windows live, or ubisoft's giant portal thing that you have to then run simultaneously (or in the right order) to get to the game.

Its definitely a rube goldberg machine in action.

I feel like the idea of sandboxing its progeny is going to need to look like docker or some sort of container where it appears to be a standard OS (since games use a lot of low level hacks) but is actually partitioned from the rest of the system.

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

#238

Post by iamtew »

akamaka wrote: 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…

Since the script is written in bash they could also have used $BASH_SOURCE, which will always point to the correct path of the script being executed, so you can do something like this:

    SCRIPT="$BASH_SOURCE"
    SCRIPT_DIR="$(dirname "$BASH_SOURCE")"

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

#239

Post by ufo »

oblio wrote: post #200
jzwinck wrote: post #165

Earlier quoted context omitted.

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.

Are these bash-exclusive or do they also work on posix-like sh?
Post reply on HN