protonscr

Steam doesn't get the free disk space properly

steamclosed
ValveSoftware/steam-for-linux#5083 · opened 2017-07-15 by cybik · updated 2018-07-28 · 2 comments · github
Ccybik 2017-07-15 github

System information

  • Steam client version (build number or date): built Jul 14 2017 at 01:07:13
  • Steam Packages Version: 1499997556
  • Distribution (e.g. Ubuntu): Gentoo
  • Opted into Steam client beta?: Yes
  • Have you checked for system updates?: Yes

Please describe your issue in as much detail as possible:

My Steam games reside on a zfs partition, and up until yesterday (with zfs 0.6.5.8) I could download games easily. It might be that the new zfs driver handles getting free space differently, but when I try to install a game now, Steam reports 0mb free on the partition, and the console logs show this:
../tier1/fileio.cpp (3264) : Assertion Failed: Failed to determine free disk space for /media/Games/cybik/Steam, error 75
Meanwhile, zfs list returns this for free space info:

NAME                                USED  AVAIL  REFER  MOUNTPOINT
CINU-S1/Games                       615G  3,21T   615G  legacy

Steps for reproducing this issue:

  1. Use zfs 0.6.5.11 on Gentoo (big request, I know)
  2. Try to install a Game on it through Steam
  3. Rage
Kkisak-valve maintainer 2017-07-15 github

Hello @cybik, this issue is already being tracked at #4982. Closing as a duplicate.

Nnonchip 2018-07-28 github

@kisak-valve is it though? the mentioned issue is mostly talking about the cli client as far as i can see (EDIT: nope it wasn't, i mistook it for #5180, but the remainder of my post still stands), and i suspect you guys not changing a single int for an uint64_t in years might be related to you thinking the (probably larger) user base for the GUI client are unaffected. fun fact: in the "manage libraries" screen you actually get it right:
st1
but trying to install a game is still forbidden because you try to make your code think for the user and get it wrong:
st2

PLEASE if you don't want to fix it at least allow us to ignore that calculation like pretty much EVERY other installer EVER does, and make that "yeah now you can't" dialog into a "you probably can't but do you want to try anyway" one.
updates to already installed games and the likes do actually work just fine, so there's no apparent reason for your code to depend on that broken calculation except "the user is stupid and we never make mistakes in our code" (which is proven wrong).

Also note this isn't zfs specific, the screenshots above happen on my 3tb ext4 drive, because of the same annoying integer overflowiness. if you people can't get your stuff to work on 64bit properly, at least make it ignorable. I'm barred from playing about 500$ worth of games because you dont have enough bits in a substraction -_-

Nothing extracted yet.