> 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, o

> 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.) Edit: it seems that it's actually glibc that's returning the error, not the kernel, see https://news.ycombinator.com/item?id=33675526 https://news.ycombinator.com/item?id=33675526