Steam has had a bit of embarrassment on Linux recently, as an oversight in one of their scripts will cause it to remove all your files, eeek!
The issue is being a bit overblown though, as you need to do some pretty specific stuff to make it happen, and it isn't just on Linux, the issue does exist in some form on Windows too. On Windows for example if you install Steam inside a folder with other data, it will remove that too:
QuoteThe uninstallation process deletes the folder Steam was installed to to ensure it is fully uninstalled. If you accidentally installed Steam to a folder containing other data, for example C:\Program Files\ instead of C:\Program Files\Steam\, STOP! Do not run the uninstaller and instead carefully follow the instructions below for Manually Removing Steam, except only delete Steam-related files in step 3.
Source
On Linux the issue has been tracked to being inside their "steam.sh" file, as it does no checking on the steam root folder.
Here is the part in question:
Quote# Scary!
rm -rf "$STEAMROOT/"*
It's amusing (in a bad way) that it even has a comment of "Scary!", so they probably knew they should have done some extra checks anyway. It's pretty basic in most languages to check something exists properly before trying to remove it.
It seems the issue arises if you move your Steam directory somehow, so if you aren't messing with moving it around and doing some linking, then you should be okay. Still, pretty scary stuff.
It should be sorted soon though, as "johnv-valve" is on the job and has plans for a fix already.
You can see the rather long bug report here. Sadly, the community seems to be quite silly and have started posting a lot of useless crap on the report, but it looks like Valve may have cleared the useless comments up.
Remember folks to keep bug reports clean as reports and feeback, don't go posting stupid memes. Article taken from GamingOnLinux.com.
0 Likes
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
It is already fixed in beta client.
These guys seem to be rather bad at bash. =/
if [ "$STEAMROOT" != "" ]; then
rm -rf "$STEAMROOT/"*
fi0 Likes
FlutterRage 17 Jan 2015
I think there are more validation checks necessary instead of just checking if the variable is empty. At least check if it's actually a directory. If I used such a bad error handling on my clients' systems I'd be in huge trouble.
3 Likes, Who?
And thats why I have another user account for running proprietary apps...
0 Likes
And thats why I have another user account for running proprietary apps...It's impossible to close source in a shell script. So a complaint about proprietary software is completely invalid here.
0 Likes
I think there are more validation checks necessary instead of just checking if the variable is empty. At least check if it's actually a directory. If I used such a bad error handling on my clients' systems I'd be in huge trouble.Yes, [[ -d "$STEAMROOT" ]] would have been a much better solution.
1 Likes, Who?
And thats why I have another user account for running proprietary apps...That is a smart idea.
0 Likes
lucifertdark 17 Jan 2015
Perhaps it's an incentive to stop people uninstalling Steam? j/k
1 Likes, Who?
Workaround :
set in your /etc/bash.bashrc :
alias rm='rm --preserve-root'
Anyway this is dangerous...
set in your /etc/bash.bashrc :
alias rm='rm --preserve-root'
Anyway this is dangerous...
0 Likes
No, --preserve-root doesn't help here (and it's enabled by default in many distributions already).
They're doing
Note the *. Which, when $STEAMROOT is empty, expands to
--preserve-root is completely okay with deleting that.
They're doing
rm -rf $STEAMROOT/*Note the *. Which, when $STEAMROOT is empty, expands to
rm -rf /bin /boot /dev [...]--preserve-root is completely okay with deleting that.
2 Likes, Who?
thelimeydragon 17 Jan 2015
I create a special file called "-i" in directories I want to keep safe.
I do this by doing:
touch ./-i
forces rm to be interactive.
I do this by doing:
touch ./-i
forces rm to be interactive.
0 Likes
I create a special file called "-i" in directories I want to keep safe.
I do this by doing:
touch ./-i
forces rm to be interactive.
Unless you go with 'rm --', IIRC.
0 Likes
I'm so glad I spend a few days last holiday to make steam run in a container!
1 Likes, Who?
No, --preserve-root doesn't help here (and it's enabled by default in many distributions already).
They're doing
rm -rf $STEAMROOT/*
Note the *. Which, when $STEAMROOT is empty, expands to
rm -rf /bin /boot /dev [...]
--preserve-root is completely okay with deleting that.
Correct me if i'm wrong, but as long as Linux security is correct and you are not running as root, rm can't touch /bin /boot /dev, etc... Can it?
1 Likes, Who?
Sure, rm won't remove /bin, etc., but it will recurse into them. It won't delete any file owned by root, but it will still go through your whole system and delete all files your user has rights to.
So yes, afterwards, your operating system will most likely still work. But all your personal data is gone.
Which is, actually, way worse. You can always reinstall your operating system, but your personal data is unique. You will need to have a backup for that.
Apropos backup: if you backup your data onto an external drive and it is still mounted, that's gone too then.
So yes, afterwards, your operating system will most likely still work. But all your personal data is gone.
Which is, actually, way worse. You can always reinstall your operating system, but your personal data is unique. You will need to have a backup for that.
Apropos backup: if you backup your data onto an external drive and it is still mounted, that's gone too then.
3 Likes, Who?
I've received a couple of warnings from readers who've had the unfortunate experience of uninstalling Half-Life, or the Sierra utilities that install with Half-Life, only to find the uninstall deleted the entire directory structure where they installed the game. The results of such a deletion could range from the annoying (the uninstallation of the Half-Life OEM or other Sierra games if you installed in the default directory), to the really problematic (if you install games in a dedicated games directory) to the truly catastrophic (if you install the game in your program files directory), so until this is fixed (or it turns out these scary anecdotes are proven incorrect), I would suggest exercising extreme caution when removing Half-Life.http://www.bluesnews.com/archives/nov98-4.html
Nothing ever changes...
0 Likes
Sure, rm won't remove /bin, etc., but it will recurse into them. It won't delete any file owned by root, but it will still go through your whole system and delete all files your user has rights to.If ever we need a reminder about the importance of not storing backups on an always mounted drive (and the importance of doing a backup), i think this is it.
So yes, afterwards, your operating system will most likely still work. But all your personal data is gone.
Which is, actually, way worse. You can always reinstall your operating system, but your personal data is unique. You will need to have a backup for that.
Apropos backup: if you backup your data onto an external drive and it is still mounted, that's gone too then.
In regards to your way worse comment, in a single user system, i agree that its way worse... But in a multiuser system, if rm had the super user power, it'd nuke everything belonging to every user on the computer. Without the ability to harm files belonging to root and other users, fortunately the damage is limited to just one user and any shared files.. Which, i will admit, is not very comforting to that user. It'd also, sadly, destroy any cloud services that sync to that user's folders too.
What i don't understand is why this happened. I mean, i'm a beginner when it comes to bash, i can make very simple scripts and that's it. And even i can see the problems with this particular script.
0 Likes
I think there are more validation checks necessary instead of just checking if the variable is empty. At least check if it's actually a directory. If I used such a bad error handling on my clients' systems I'd be in huge trouble.Yes, [[ -d "$STEAMROOT" ]] would have been a much better solution.
But doesn't that just make sure it's a directory? if the variable is empty then it runs like it did before but will only delete say... your home directory?
If anything I was trying to think of a safe way of doing this, maybe making the /* part of the variable name so if its empty the entire string is empty? Or just have it rm -rf $steampath, so if empty it basically does nothing? In the past when it comes to deleting things I had the rm command grep the target against a list to make sure it was only deleting something I gave permission too.
I'm curious to what everyone thinks tbf, always happy picking up scripting ideas.
0 Likes
I hop they fix this soon. Steam just deleted all of my games It downloaded an update and BOOM!
0 Likes
But doesn't that just make sure it's a directory? if the variable is empty then it runs like it did before but will only delete say... your home directory?That's not how it works. If the test fails to run (the result is false), if statement goes to the next elif (if present) or to the else. You can always check it for yourself:
var=''
if [[ -d "$var" ]]; then
echo 'will work anyway'
else
echo 'will fail'
fi
0 Likes
Cheeseness 21 Jan 2015
I hop they fix this soon. Steam just deleted all of my games It downloaded an update and BOOM!
In case you didn't spot the first comment, the issue that this article about has already been resolved.
Regarding games being removed, this is a thing that I've seen a number of times. So long as you don't download anything, it'll be there when you next start Steam.
0 Likes
Patreon
PayPal
How to set, change and reset your SteamOS / Steam Deck desktop sudo password
How to set up Decky Loader on Steam Deck / SteamOS for easy plugins
See more from me