This mainly affects zip builds and when running a local build from the object directory. When those are run the update directory falls back to using %LOCALAPPDATA%\Firefox\firefox\ One problem with this is that after an update has been applied the PostUpdate process typically creates the correct updates directory. This will make it so the correct update directory is used in almost all cases (at least the ones that I care about). Note: I will likely use this to also implement a mutex on Windows to fix bug 1112937

Pushed to try https://treeherder.mozilla.org/#/jobs?repo=try&revision=eda5f23e2a67467f2f3952114c04773b550babde

It doesn't look like mochitest-o runs the mochitest other tests anymore so I pushed again to try specifying all mochitests https://treeherder.mozilla.org/#/jobs?repo=try&revision=40c1ce307d0c69b81041e0c44828c9d25ac4edbf

Comment on attachment 8848830 [details] [diff] [review] patch rev2 - improved comment Not sure what is going on with try and mochitests. I ran them locally and they passed.

Comment on attachment 8848830 [details] [diff] [review] patch rev2 - improved comment Review of attachment 8848830 [details] [diff] [review]: ----------------------------------------------------------------- I'm fine with mhowell's sign-off here.

Pushed by rstrong@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/58715d87a712 Use the installation dir path CityHash hash for the updates directory even when the hash hasn't been written to the registry by the installer. r=mhowell, r=dtownsend

Any idea why a local clobber build of Thunderbird now fails with a link error: 82:59.93 Unified_cpp_toolkit_xre0.obj : error LNK2019: unresolved external symbol "unsigned __int64 __cdecl CityHash64(char const *,unsigned __int64)" (?CityHash64@@YA_KPEBD_K@Z) referenced in function "public: enum nsresult __cdecl nsXREDirProvider::GetUpdateRootDir(class nsIFile * *)" (?GetUpdateRootDir@nsXREDirProvider@@QEAA?AW4nsresult@@PEAPEAVnsIFile@@@Z) I've just fixed some other bustage, so let's see what the tree says in a little while: https://treeherder.mozilla.org/#/jobs?repo=comm-central

Some treeherder results have become available, this only breaks builds on Windows. Filed bug 1349894.

Looks like a problem in TB's build config, it wasn't picking up the: http://searchfox.org/mozilla-central/rev/9af9b1c7946ebef6056d2ee4c368d496395cf1c8/browser/components/shell/moz.build#33 Sorry about the noise.