Is Linux really not commonly using 64-bit file times yet? I know there are some years left, but it seems like a relatively straightforward problem that needs to be solved for everyone.
> Is Linux really not commonly using 64-bit file times yet?
It is, and that was the problem. The legacy 32-bit API the library loaded within Steam was using, or more precisely, the legacy 32-bit system call used by that library, could not represent the 64-bit time, so the kernel returned the EOVERFLOW (Value too large for defined data type) error. The root cause of the problem seems to be that Steam is still a 32-bit application (and hasn't been recompiled to used the Latest and Greatest version of glibc, which allows for 64-bit timestamps even on 32-bit processes).
If his Linux installation did not use 64-bit file times, the timestamp stored for the file would have fit in 32 bits, and the error wouldn't have happened (though other things would probably have broken first).
(Well, actually, Linux is using 34-bit file times, at least on ext4 and xfs, but that's a bit of a nitpicking: what matters is that it doesn't fit in 32 bits.)
The Steam client is super old and crusty. Ubuntu tried to remove 32 bit libraries like Apple a while ago but Valve told them if they did that, Steam would no longer be supported so the plan was scrapped.
Even if Valve finally get around to updating the client to 64-bit (it already is on macOS AFAIK), most old games are not going to be updated so insisting on keeping the 32-bit libraries around is the right thing to do. Keep in mind that the distro just needs to supply the base system (libc, OpenGL drivers, etc.) in 32-bit and Steam already comes with copies of everything else via the steam runtime.
