Closed Bug 1510276 Opened 2 years ago Closed 2 years ago

Inconsistent drive letter case leading to invalid/duplicated registry entries


(Firefox :: Installer, enhancement, P3)




Firefox 67
Tracking Status
firefox67 --- fixed


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




(1 file)

Under HKLM Software\Clients\StartMenuInternet\Firefox-A3710B8EBB50CD3 I noticed a registry entry with a shell\open\command path that starts with a lowercase c.
"c:\Program Files\Nightly\firefox.exe"

When I already have HKLM Software\Clients\StartMenuInternet\Firefox-4FD8BA6A4A33F689 a shell\open\command that starts with an uppercase C
"C:\Program Files\Nightly\firefox.exe"

Interestingly, I only have FirefoxHTML-A3710B8EBB50CD3 and FirefoxURL-A3710B8EBB50CD3 under HKLM Software\classes and they both start with the uppercase C.

I've also noticed a couple of HKLM Software\classes\FirefoxHTML-<hash> and HKLM Software\classes\FirefoxURL-<hash> keys that only have shell\open\ddeexec and their values but don't have shell\open\command or DefaultIcon.
Bah, just noticed that HKLM Software\Clients\StartMenuInternet\Firefox-A3710B8EBB50CD3 has the uppercase C and HKLM Software\Clients\StartMenuInternet\Firefox-4FD8BA6A4A33F689 has the lowercase c which makes much more sense.
Yeah, this sounds like $INSTDIR is getting initialized with inconsistent drive letter casing. I'm not sure how that's happening, presumably NSIS is setting $EXEDIR that way, but in any case that difference then causes ${InitHashAppModelId} to generate different hashes. I guess ${GetLongPath} needs to be normalizing the case of the drive letter. And once that's happening we should also probably take steps to make sure we don't create duplicate entries for installs that had previously always used the other case.
Priority: -- → P3
Summary: Invalid registry entries created by the installer code → Inconsistent drive letter case leading to invalid/duplicated registry entries

Always uppercase the first char of the path in GetLongPath
Remove GetLongPathNameW since it isn't setting the proper case for the path segments below the leaf name

Assignee: nobody → robert.strong.bugs
Pushed by
Fix GetLongPath so it returns the proper case for the path. r=mhowell
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 67
You need to log in before you can comment on or make changes to this bug.