Skip to content

Moved ~/.local/share/steam. Ran steam. It deleted everything on system owned by user. #3671

Closed
Closed
Moved ~/.local/share/steam. Ran steam. It deleted everything on system owned by user.#3671
Labels
reviewed

Description

@keyvin
keyvin
opened on Jan 14, 2015

Edit: Please stop posting stupid image memes or unhelpful messages. This interferes with Valve's ability to sift through the noise and see if anyone can figure out what triggers it.

This may not be a common problem because I change all sorts of configuration about my system. The script in question does something in a really, really stupid way, but it probably doesn't trigger the fail scenario for every system because...

Original Bug:
I am not sure what happened. I moved the folder in the title to a drive mounted under /media/user/BLAH and symlinked /home/user/.local/steam to the new location.

I launched steam. It did not launch, it offered to let me browse, and still could not find it when I pointed to the new location. Steam crashed. I restarted it.

It re-installed itself and everything looked great. Until I looked and saw that steam had apparently deleted everything owned by my user recursively from the root directory. Including my 3tb external drive I back everything up to that was mounted under /media.

Everything important, for the most part, was in the cloud. It is a huge hassle, but it is not a disaster. If there is the chance that moving your steam folder can result in recursively deleting everything in the directory tree you should probably just throw up an error instead of trying to point to other stuff. Or you know, allow the user to pick an install directory initially like on windows.

My system is ubuntu 14.04, and the drive I moved it to was ntfs if its worth anything.

Activity

  1. doofy commented on Jan 15, 2015

    @doofy
    doofy
    on Jan 15, 2015

    I am impressed how calm you stay about this. This is terrible. I just lost my home directory. All i did was start steam.sh with STEAM_DEBUG=1. I will investigate this and report back.

    edit1: I suspect steam.sh got some bugs(does not check own variables) and when it tried to do scary things it crapped himself.
    Line 468: rm -rf "$STEAMROOT/"*

    edit2: It gets better. Seems on windows Steam is overeager too! https://support.steampowered.com/kb_article.php?ref=9609-OBMP-2526 (The warning part is interesting. Because everybody reads this before uninstalling...)

  2. Tele42 commented on Jan 15, 2015

    @Tele42
    Tele42
    on Jan 15, 2015

    I agree, that line minimally requires an exists and not null check for $STEAMROOT

  3. keyvin commented on Jan 15, 2015

    @keyvin
    keyvin
    on Jan 15, 2015
    Author

    #scary!

    As an ex programmer, that really makes me chuckle. Can I at least get an apology from whoever committed that comment without adding a fix?

  4. CamilleScholtz commented on Jan 15, 2015

    @CamilleScholtz
    CamilleScholtz
    on Jan 15, 2015

    This also happened to me a few weeks ago, my entire home was deleted by the steam.sh script.

  5. pythoneer commented on Jan 15, 2015

    @pythoneer
    pythoneer
    on Jan 15, 2015

    introduced here Sep 10, 2013 https://github.com/indrora/steam_latest/commit/21cc14158c171f5912b04b83abf41205eb804b31 line 359

    rm -rf "$STEAMROOT/"* could be evaluated as rm -rf "/"* if $STEAMROOT is empty

    but what exactly caused this? i've symlinked ~/.local/share/steam to, so i am a bit afraid to start steam :/

  6. TcM1911 commented on Jan 15, 2015

    @TcM1911
    TcM1911
    on Jan 15, 2015

    pythoneer,

    I believe the issue starts on line 19:

    # 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)"
STEAMDATA="$STEAMROOT"

    This probably returns as empty which mean: rm -rf "$STEAMROOT/"* is the same ass rm -rf "/"*.

  7. pythoneer commented on Jan 15, 2015

    @pythoneer
    pythoneer
    on Jan 15, 2015

    TcM1911,

    that's my guess, too.

  9. jthill commented on Jan 15, 2015

    @jthill
    jthill
    on Jan 15, 2015

    Yeah, they kinda need a readlink in there.

    STEAMROOT=$(readlink -nf "${0%/*}")

  10. jthill commented on Jan 15, 2015

    @jthill
    jthill
    on Jan 15, 2015

    @minio Not "only if". reset_steam is also invoked by removing your .steam directory, since that sets INITIAL_LAUNCH

  11. soren121 commented on Jan 15, 2015

    @soren121
    soren121
    on Jan 15, 2015

    @minio A script accidentally running rm -rf /* is unacceptable in any scenario.

  12. gtmanfred commented on Jan 15, 2015

    @gtmanfred
    gtmanfred
    on Jan 15, 2015

    it is like bumblebee all over again!
    MrMEEE/bumblebee-Old-and-abbandoned#123

  13. Plaque-fcc commented on Jan 15, 2015

    @Plaque-fcc
    Plaque-fcc
    on Jan 15, 2015

    I encountered Steam behaviour like with «--reset» for several times:
    when I added «--reset» AND when I didn't. So — not «only if», can
    confirm this, even having not deleted ~/.steam/ dir, too.

  14. prometheanfire commented on Jan 15, 2015

    @prometheanfire
    prometheanfire
    on Jan 15, 2015

    wonder what the code path is to hit that rm without --reset

  15. indrora commented on Jan 15, 2015

    @indrora
    indrora
    on Jan 15, 2015

    Can confirm; I have Steam bounded in an SELinux context ("Steam") and SELinux spits out:

    Context violation: process /home/indrora/.local/share/Steam/ubuntu12_32/steam is only allowed in context steam_context, attempted to remove /boot/efi/grub/efistub

    Ooops. I'll write a patch and PR it 🍺

  16. 248 remaining items

  17. user15177 commented on Nov 28, 2017

    @user15177
    user15177
    on Nov 28, 2017

    Has this problem been fixed? I really want to play the metro series, but this scares the crap out of me.

  19. alphapapa commented on Jan 1, 2018

    @alphapapa
    alphapapa
    on Jan 1, 2018

    @craig-sanders Since you posted some cleaned-up code from the script and some good Bash scripting advice, a note: Always use the [[ ]] test syntax in Bash-specific scripts. It's safer and cleaner in all cases.

  20. ethomson
    added a commit that references this issue on Feb 19, 2019

    dev.sh: remove files carefully

    e75b1e0
  21. TingluoHuang
    added a commit that references this issue on Feb 19, 2019

    dev.sh fixups (#2114)

    d3575d5

  22. aviwad commented on Mar 17, 2019

    @aviwad
    aviwad
    on Mar 17, 2019

    Is this fixed? xD

  23. aviwad
    unassigned
    johnv-valve
    on Mar 17, 2019

  24. aviwad commented on Mar 17, 2019

    @aviwad
    aviwad
    on Mar 17, 2019

    whoa what the heck does the unassigned message mean

  25. aaronfranke commented on Mar 17, 2019

    @aaronfranke
    aaronfranke
    on Mar 17, 2019

    @aviwad It's just something GitHub does automatically when the assigned person doesn't actually do anything about the issue and someone comments on it again.

  26. nicklleite commented on Apr 30, 2021

    @nicklleite
    nicklleite
    on Apr 30, 2021

    Its still happening. It deleted almost everything on my Ubuntu.

  27. kisak-valve commented on Apr 30, 2021

    @kisak-valve
    kisak-valve
    on Apr 30, 2021
    Member

    Hello @nicklleite, the investigation of the issue in this issue report concluded several years ago. Please open a new issue report.

  29. antdude commented on Jun 2, 2021

    @antdude
    antdude
    on Jun 2, 2021

    ?

  30. ValveSoftware
    locked as resolved and limited conversation to collaborators on Jun 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    reviewed

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions