Closed Bug 1348609 Opened 7 years ago Closed 7 years ago

Use the installation dir path hash for the updates directory even when the hash hasn't been written to the registry

Categories

(Toolkit :: Application Update, defect)

All
Windows
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla55
Tracking Status
firefox55 --- fixed

People

(Reporter: robert.strong.bugs, Assigned: robert.strong.bugs)

References

Details

Attachments

(1 file, 1 obsolete file)

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
Assignee: nobody → robert.strong.bugs
Status: NEW → ASSIGNED
OS: Unspecified → Windows
Hardware: Unspecified → All
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
Attachment #8848823 - Attachment is obsolete: true
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.
Attachment #8848830 - Flags: review?(mhowell)
Attachment #8848830 - Flags: review?(mhowell) → review+
Attachment #8848830 - Flags: review?(dtownsend)
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.
Attachment #8848830 - Flags: review?(dtownsend) → review+
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
https://hg.mozilla.org/mozilla-central/rev/58715d87a712
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
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
Flags: needinfo?(robert.strong.bugs)
Flags: needinfo?(mhowell)
Flags: needinfo?(dtownsend)
Blocks: 1349894
Some treeherder results have become available, this only breaks builds on Windows. Filed bug 1349894.
No longer blocks: 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.
Flags: needinfo?(robert.strong.bugs)
Flags: needinfo?(mhowell)
Flags: needinfo?(dtownsend)
Depends on: 1358790
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: