I assume this is related to Bug 1555319 as this happened after I upgraded to 69. When I opened Firefox after restart I saw a fresh profile (no tabs). I also saw a message that Firefox is not a default browser (which was not true because all links o[en this Firefox).

Back in May I already had installs.ini generated and it was this:

[4CFB19B500358245]
Default=Profiles/q0ka2h97.dev-edition-default

[B05481E4AB3A185A]
Default=Profiles/4c01c8gp.default
Locked=1

And now I see two new installations and one new profile. So now I have 4 installs:

[93128373CC40060B]
Default=Profiles/fzu8h2pe.default-release
Locked=1

[4CFB19B500358245]
Default=Profiles/q0ka2h97.dev-edition-default

[385C2A9B08EA562F]
Default=Profiles/q0ka2h97.dev-edition-default

[B05481E4AB3A185A]
Default=Profiles/4c01c8gp.default
Locked=1

The fzu8h2pe.default-release is a new profile and 4c01c8gp.default is my actual profile.

Also profiles.ini is just a mess now. Not sure if this is expected but Firefox is not respecting Default=1 for my profile and opens locked profile instead.

[Install93128373CC40060B]
Default=Profiles/fzu8h2pe.default-release
Locked=1

[Profile2]
Name=default-release
IsRelative=1
Path=Profiles/fzu8h2pe.default-release

[Install4CFB19B500358245]
Default=Profiles/q0ka2h97.dev-edition-default

[Profile1]
Name=dev-edition-default
IsRelative=1
Path=Profiles/q0ka2h97.dev-edition-default

[Profile0]
Name=default
IsRelative=1
Path=Profiles/4c01c8gp.default
Default=1

[Install385C2A9B08EA562F]
Default=Profiles/q0ka2h97.dev-edition-default

[General]
StartWithLastProfile=1
Version=2

[InstallB05481E4AB3A185A]
Default=Profiles/4c01c8gp.default
Locked=1

And I have no idea if I even need those all installs and what the hash means.

What operating system are you using and what is the installation path for the Firefoxes you have on your machine (can be viewed in about:support).

Windows 7 x64

Regular:

c:\Programy\Sieciowate\Mozilla\Firefox\firefox.exe
20190827005903
C:\ProgramData\Mozilla\updates\B05481E4AB3A185A 
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0

Dev:

c:\Programy\Sieciowate\Mozilla\Firefox Developer Edition\firefox.exe
20190909162732
C:\ProgramData\Mozilla\updates\4CFB19B500358245 
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0

Files in the updates directory below. Seems like it contains the new installs id (93128373CC40060B).

c:\ProgramData\Mozilla\updates\4CFB19B500358245\update-config.json
c:\ProgramData\Mozilla\updates\4CFB19B500358245\updates.xml
c:\ProgramData\Mozilla\updates\4CFB19B500358245\updates\backup-update.log
c:\ProgramData\Mozilla\updates\4CFB19B500358245\updates\last-update.log
c:\ProgramData\Mozilla\updates\93128373CC40060B\update-config.json
c:\ProgramData\Mozilla\updates\B05481E4AB3A185A\update-config.json
c:\ProgramData\Mozilla\updates\B05481E4AB3A185A\updates.xml
c:\ProgramData\Mozilla\updates\B05481E4AB3A185A\updates\backup-update.log
c:\ProgramData\Mozilla\updates\B05481E4AB3A185A\updates\last-update.log

Can you attach a copy of Profiles\fzu8h2pe.default-release\compatibility.ini

Hm... Interesting, I see what happened. I'm quite sure I have no links to "U" drive for Firefox, but that is the physical drive it resides on.

[Compatibility]
LastVersion=69.0_20190827005903/20190827005903
LastOSABI=WINNT_x86_64-msvc
LastPlatformDir=U:\Programy\Sieciowate\Mozilla\Firefox
LastAppDir=U:\Programy\Sieciowate\Mozilla\Firefox\browser

"c:\Programy" is an NTFS junction to "u:\Programy".

Ah. Something along the way is resolving the junction to its target and launching firefox.exe from there and so that's where we think Firefox is installed. I'm assuming that the Profiles/4c01c8gp.default/compatibility.ini lists the C:\Programy version?

I wonder if the updater is doing this somewhere, any thoughts Robert?

Adam, I don't recall the updater changing any paths that are passed to it. Could you check if it does? Thanks!

I can't think of anything that would change the paths like that.

Matt, does this suggest anything to you?

Is it possible that GetModuleFileName (as used by the launcher process and ultimately how the path gets into compatibility.ini) would report the resolved path in some cases? It doesn't seem to do that if I just set up a junction on the same filesystem with mklink /J (and GetLongPathName or PathCanonicalize don't do it, either), but I don't know if it would be handled differently if pointing out of the filesystem. Probably not?

I can't find anything in the hg logs that would have changed to cause us to start resolving junctions in the launcher process, or in the update directory determination, or in any of the nsIFile stuff that it's connected to. I also tried GetModuleFileName(nullptr...) on a path that goes through a cross-volume junction, and it did not resolve the junction (and I don't think GetLongPathName or PathCanonicalize will ever resolve links). So I don't have any idea what could have changed to start causing this, sorry...

As a follow up...

I'm assuming that the Profiles/4c01c8gp.default/compatibility.ini lists the C:\Programy version?

Surprisingly, no. It's on U:\ too.

Last backup I have from June 2019 of 4c01c8gp.default/compatibility.ini:

LastVersion=67.0_20190516215225/20190516215225
LastOSABI=WINNT_x86_64-msvc
LastPlatformDir=C:\Programy\Sieciowate\Mozilla\Firefox
LastAppDir=C:\Programy\Sieciowate\Mozilla\Firefox\browser

Then right after update to 69 (but before actually using the profile in 69) it was:

[Compatibility]
LastVersion=68.0.2_20190813150448/20190813150448
LastOSABI=WINNT_x86_64-msvc
LastPlatformDir=U:\Programy\Sieciowate\Mozilla\Firefox
LastAppDir=U:\Programy\Sieciowate\Mozilla\Firefox\browser

And now it is:

[Compatibility]
LastVersion=69.0_20190827005903/20190827005903
LastOSABI=WINNT_x86_64-msvc
LastPlatformDir=U:\Programy\Sieciowate\Mozilla\Firefox
LastAppDir=U:\Programy\Sieciowate\Mozilla\Firefox\browser

If I do a fresh install into a directory which is a junction to another directory (via mklink /J), compatibility.ini will get the resolved path; this is the case at least back to 56.0 when ResolveJunctionPointsAndSymLinks() was used to normalize GREDir when content sandboxing was configured. Content processes run from the resolved path, but the main process is still run with whatever path it was launched with (even with the launcher process).

I haven't been able to figure out why the compatibility.ini for 67 wouldn't have used U:. If I install 55.0 (the last version without bug 1369670), it uses the original path (would be C: in this case), but as soon as I run 56.0 it changes to the resolved path (would be U:). So there may be something else odd going on here.

As mentioned earlier, bug 1555319 uses ResolveJunctionPointsAndSymLinks() to normalize the path here; this is only for the path hash but it might be involved with why we think there is a different installation now? Updating from 68 to 69 doesn't seem to cause any issues, though, so I think the "Legacy Install" stuff is working properly.

I've only moved to U drive recently so maybe that's the difference from your tests.

I would assume the installation ID would not be changed just because I mounted my folder somewhere else (at least as long as I keep all lnk links the same). Maybe you could associate execution paths with an installation id and just keep an id the same as long as the same exe from the same path is executed.

(In reply to Maciej Jaros from comment #11)

I've only moved to U drive recently so maybe that's the difference from your tests.

Can you remember when you made that switch, was it before you updated to 67 (67 was released May 21st) or after?

I created U:\Programy on 2019-06-05... That was definitely after upgrading to FF67. I know because I had a drive failure and FF stopped working (nothing was loading, even localhost). Back then I assumed that was because of the drive failures (FF was working without extensions so I assumed one of them had broken data). I refreshed the profile and it started working fine.

I've moved to U after doing all that so I was using FF67 already.

Oh and previously "C:\Programy" wasn't a real folder either. It was a mount point for an NTFS partition from the start. So it was never really on the C drive.

So:

1. Running Firefox 67 (out of C:\Program Files?).
2. Installed Firefox 67 to U drive, made a junction point to C:\Programy, started running Firefox from there (did you switch profile or anything at this point?
3. Later upgraded to 69 and then this profiles issue happened.

Setting needinfo on myself so I can test this out tomorrow

I did try this out but all my thoughts came to nothing. I cannot reproduce this even with junction points in the mix.

After upgrading to Firefox 72 It creates two empty new profiles, loosing bookmarks, certificates, etc

Maciej, does this still reproduce for you?

No, I fixed that manually long time ago. And I reinstalled my system anyway due to other reasons... and I don't use custom paths for Firefox profiles anymore. Just in case 😉