Updated: Steam on Mac OS X

Further to my 2010(!) post Installing Steam on Mac OS with a Case-sensitive boot partition Steam is now, if anything, even more broken on Mac OS – and this is particularly odious given that a Linux Steam client is now available which operates under the same conditions, but handles itself correctly.

Valve, why do you hate Mac gamers?

The actual failure mode is fairly interesting:

After installing Steam I was asked to sign-in or create a new account, and on signing-in I was (correctly) asked for a SteamGuard code, which was also emailed. I provided this and Steam worked correctly.

I proceeded to change the Download Region to the location nearest to me, and Steam announced that it would need to restart. On restarting, I was immediately prompted for a SteamGuard code without any option to re-send a code, and no code was emailed to me. Cancelling this SteamGuard prompt returned me to the login page, and attempting to login again showed the same behaviour: I was immediately prompted to enter a code without any code having been sent.

On cancelling this (which causes Steam to quit) and restarting Steam, I was this time first asked to enter my login details (which I wasn’t before), and on entering these I was prompted with the familiar “I’ve received the message from Steam Support”/”What email message?” dialog-window which was not shown before – and I also received a code by email. On entering this code (and ensuring that “Remember this computer” was ticked), Steam client logged-in successfully.

However, when I then quit Steam and restarted it, I was not asked for login details but immediately prompted for SteamGuard verification again – despite having just authorised. I received a code via email – however, after correctly entering this code, I’m taken back to the login page again. This time, on re-entering the correct account details I was instantly taken back to the “My special access code is:” prompt without having been asked if I’ve received a code (the “I’ve received the message from Steam Support”/”What email message?” view seen previously) – and no new code had been sent. I did try with the previously just-used code, but this no longer worked.

On quitting and re-launching Steam again, I was immediately asked for login details (not a code), asked if I’d received a code (“I’ve received the message from Steam Support”/”What email message?”) – but this time, a code was emailed, and so I could login.

After a final quit and relaunch, and I was again instantly prompted for a code (which was emailed), then asked to login again, then asked for a second code (which wasn’t emailed).

Logins alternate between these two cases, only allowing use of Steam 50% of the time.

(On seeing a SteamGuard prompt but then cancelling rather than providing login details – causing Steam to quit – after relaunch I again see a SteamGuard prompt immediately – so it’s the action of signing-in to the account rather than the action of loading Steam which alternates between SteamGuard working and SteamGuard failing)

Having to login twice is annoying, but the main problem is that if I leave the Steam running in the background then I’ll eventually be asked to re-authorise SteamGuard while Steam is still running, but again will be taken straight to the Enter Code dialog without having been sent a code. The interesting thing, as mentioned above, is that in this case if I choose to cancel (to be taken back to a login dialog) then I’ll always be told that I’ve entered the wrong credentials, even if I’ve entered the right password.

Steam support were utterly unhelpful in resolving this problem, even though the case persisted for over four months and forty-two messages exchanged.

Eventually (I don’t know why I didn’t try this earlier, to be honest), I decided to look into why it wasn’t working in detail.

Firstly I note that Steam’s cross-platform ‘steam.sh‘ script is pretty poor to say that it comes from a company which distributes its own Linux OS: the method it uses to work out where Steam is installed will fail if steam.sh isn’t executed directly (e.g. if you run ‘/bin/bash steam.sh‘ then it thinks it’s installed in /bin), and it has a tendency to call ‘exit -1‘, which is invalid since ‘exit‘ accepts only an unsigned argument*.

(*) … although this in itself will wrap-around to actually cause ‘exit 255‘ to be executed, which may have other semantic issues…

I had noticed in the Steam connection_log.txt log file, amongst a scary number of 'Invalid Login Auth Code' events, the occasional entry reading:


SteamClient: Failed to save sentry file


… which gave me something to work with. Looking at the dtruss output, which consisted of hundreds of megabytes of syscalls, this let me find out exactly what they’re doing wrong:

Steam is trying to write a 2 kilobyte file to ‘/users/user/library/application support/steam/ssfnnumber‘. This is on a system where, since launch, this path would always have been ‘/Users/user/Library/Application Support/‘.

Rather than fix this with symlinks all the way, I created (and then hid with ‘chflags -h /users‘) a symlink from /users to the volume I use to store Steam games, and then create the remaining elements of the required path below there using standard directories. This feels like a cleaner approach.

Note that Steam will fail with an alert if ~/Library/Application Support/steam is itself on a case-sensitive filesystem – but will happily access the ‘~/Library/Application Support‘ element with the appropriate case except when it comes to SteamGuard, when it issues no warning other than the rather unhelpful log entry above.

Basic programming good-practice should dictate that if you’re going to log an error that a file-operation failed, you should at least log either the name of the file in question or at least the directory beneath which the problem occurred…

As mentioned, what is especially exasperating about this is that the Linux client – which, from the looks of the ‘steam.sh‘ script and other Steam-supplied files, must share a significant amount of infrastructure with the Mac client – has to get this right. It must surely at this point be more effort for Valve to maintain the differences between these two clients (where the Linux edition works in case-sensitive environments but the Mac one has a stack of random capitalisation) than simply to merge the updates into both and be done with it.

Grr…

Update: Just after writing this, a significant Steam update was released – the Mac version now as a Yosemite-like round icon, and ‘steam.sh‘ is just a stub – which at least neatly sidesteps the scripting issues. Whilst Valve haven’t actually fixed Steam’s case-sensitivity issues, they have now protected it from running under ‘dtruss‘. So yay, I guess 🙁