In a retrospective, [Kevin Fang] takes us back to 2015, when on the Steam for Linux issue tracker [keyvin] opened an issue to report that starting the Steam client after moving the Steam folder had just wiped all of his user data, including his backup drive mounted under /media. According to [keyvin], he moved the standard ~/.local/share/steam to a drive mounted under /media and symlinked ~/.local/share/steam to this new location on the external drive. He then tried starting Steam, which failed, before Steam crashed and tried reinstalling itself. That’s when [keyvin] realized that Steam had apparently recursively deleted everything owned by his user from the root folder.
In the issue thread, user [doofy] got hit by the same bug when trying to directly start the ~/.local/share/steam/steam.sh script with debugging enabled. He then was the first to point out the rm -rf in that steam.sh script, but since this particular line is in a function only called when Steam tries to remove and reinstall itself to ‘fix’ a botched start, how did this happen? Ultimately it seems to be because of the STEAMROOT variable being set to an empty string, and another unset variable triggering the reset_steam() function, leading to the demise of all the user data.
Since then Valve has presumably fixed the issue, as no further users have filed tickets, but it’s concerning that a similar issue seems to still exist on Windows. Whether or not the original Linux issue has been fixed, it shows clearly how one should always check return values and perhaps, just maybe, never do an automated rm -rf or equivalent.
0 Commentaires