1765189 - Symlink disappears after an update (FF ESR)

Status: RESOLVED WONTFIX

(Toolkit :: Application Update, defect)

Description

[serpher]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0

Steps to reproduce:

Make symlink for policies.json and then update ESR with incremental update for ex. 91.4.0 to 91.5.0

Actual results:

policies.json has lost symlink and now exists as a standalone file

Expected results:

symlink to a policies.json should be there after an update

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Toolkit::Application Update' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[[e-mail] (:bhearsum)]

Thank you for the report! I was unable to trivially reproduce unfortunately. A few more details may help here:

• Can you attach the information from "about:support" using the button at the top of that page?
• It looks like you're on Windows -- how did you create the link?
• Please attach your latest update logs with these steps:
  1. Navigate to about:support
  2. Find the "Update Folder" entry and click "Open Folder".
  3. Open the updates directory.
  4. Inside, you should find files named last-update.log and backup-update.log. Attach these files to this bug.

Comment 3

[serpher]

Attachment: About:support

Comment 4

[serpher]

Attachment: backup-update.log

I used mklink to create symlink to remote location \\192.168.1.50\policies.json

Comment 5

[serpher]

Attachment: backup-update.log

I used mklink to create symlink to remote location \\192.168.1.50\policies.json

Comment 6

[serpher]

I used mklink to create symlink to remote location \192.168.1.50\policies.json

Comment 7

[serpher]

last-update.log

Performing a replace request
PATCH DIRECTORY C:\ProgramData\Mozilla\updates\308046B0AF4A39CB\updates\0
INSTALLATION DIRECTORY C:\Program Files\Mozilla Firefox
WORKING DIRECTORY C:\Program Files\Mozilla Firefox\updated
Begin moving destDir (C:\Program Files\Mozilla Firefox) to tmpDir (C:\Program Files\Mozilla Firefox.bak)
rename_file: proceeding to rename the directory
Begin moving newDir (C:\Program Files\Mozilla Firefox.bak/updated) to destDir (C:\Program Files\Mozilla Firefox)
rename_file: proceeding to rename the directory
Now, remove the tmpDir
ensure_remove: failed to remove file: C:\Program Files\Mozilla Firefox.bak/updater.exe, rv: -1, err: 13
ensure_remove_recursive: unable to remove directory: C:\Program Files\Mozilla Firefox.bak, rv: -1, err: 41
Removing tmpDir failed, err: -1
remove_recursive_on_reboot: file will be removed on OS reboot: C:\Program Files\Mozilla Firefox\tobedeleted\rep1e6cfb77-0e0d-472b-a723-ac2124a7008e
succeeded
calling QuitProgressUI

Comment 8

[serpher]

I think it's due to moving directories by the updater. Windows loses the original path.

Comment 9

[[e-mail] (:bhearsum)]

(In reply to serpher from comment #8)

I think it's due to moving directories by the updater. Windows loses the original path.

This seems quite likely. From https://docs.microsoft.com/en-us/windows/win32/fileio/symbolic-link-effects-on-file-systems-functions#copyfile-and-copyfiletransacted, this is the default behaviour: "If the source file is a symbolic link, the actual file copied is the target of the symbolic link."

It looks like there are workarounds for this. Specifically, https://docs.microsoft.com/en-us/windows/win32/fileio/symbolic-link-effects-on-file-systems-functions#copyfileex talks about setting COPY_FILE_COPY_SYMLINK when calling CopyFileEx which will cause the symlink to be copied rather than the target file.

If I'm reading the current code correctly, we ultimately use _wrename right now (defined here, used by rename_file, which is called by ProcessReplaceRequest.

There's actually a comment in the header right now that says _wrename is used to avoid the link tracking service, which makes me wonder if moving to CopyFileEx is even a possiblity. (This appears to be the Link Tracking Service referenced], and another comment that implies we assume that symlinks don't exist on Windows.

Kirk, I think your expertise is warranted here. Specifically:

• Does the above interpretation make sense?
• If so, can/should we try to handle symlinks within the appdir better?

Comment 10

[Robin Steuber (she/her) [:bytesized]]

(In reply to [e-mail] (:bhearsum) from comment #9)

Kirk, I think your expertise is warranted here. Specifically:

• Does the above interpretation make sense?

Looks reasonable to me.

• If so, can/should we try to handle symlinks within the appdir better?

Hmm. I have a couple of thoughts here.

• I am a little nervous about getting bitten by the link tracking service. We really don't want to break the links to Firefox when we update. I only briefly skimmed over that article, so I'm not sure how hard it is to ensure that we do this properly.
• I am nervous about security issues here. Off the top of my head, I don't see any big, red flags. But messing with links in a privileged context has bitten me before, so I'm wary.
• It just doesn't seem necessary to support this. The only use case that is coming to mind would be allow multiple installations of Firefox to be managed centrally. But we already support that, via Windows Group Policies. And I don't really see any reason to reinvent a worse version of that feature.

So I'm going to tentatively say that we shouldn't support this. However, I want to know if there is a reason for supporting it that I am missing.

@serpher Why do you want to be able to do this?

Comment 11

[serpher]

@kirk
If it's not possible due to various reasons, that's fine I guess.
I was utilizing policies.json via symlink as a substitute to Group Policies. In our environment we can't put everyone on internal domain. Symlink seemed to be a solution to a degree. Updater working as is breaks it most of the time leaving the last version in the folder. Scheduled Tasks could be the solution going forward (recreate symlink on OS startup). Kinda hassle but what can you do.

I'd like to thank you both so much for actually lean over that problem!

Comment 12

[[e-mail] (:bhearsum)]

(In reply to serpher from comment #11)

@kirk
If it's not possible due to various reasons, that's fine I guess.
I was utilizing policies.json via symlink as a substitute to Group Policies. In our environment we can't put everyone on internal domain. Symlink seemed to be a solution to a degree. Updater working as is breaks it most of the time leaving the last version in the folder. Scheduled Tasks could be the solution going forward (recreate symlink on OS startup). Kinda hassle but what can you do.

I'd like to thank you both so much for actually lean over that problem!

Thank you for the detailed bug report and follow-ups -- it really helps get to the bottom of these bugs.

Comment 13

[Robin Steuber (she/her) [:bytesized]]

I'm hesitant to recommend this, but probably your symlink would stay intact if you set app.update.staging.enabled to false. By default, we stage updates by essentially installing them to <installdir>/updated and then just swapping the old one for the updated one when Firefox starts.

Turning off staging would mean that the whole update would have to be performed at Firefox launch time. And a whole update takes longer than swapping an already-staged update. Meaning that Firefox would seem to start quite a bit more slowly when there is an update pending. But, IIRC, non-staged updates basically patch the installation in-place rather than installing to a separate location and swapping them. So that might prevent the symlink from being removed.

I'm not sure if that is preferable to you over a scheduled task or a Group Policy, but I thought I would mention it.

Comment 14

[serpher]

@kirk
Thank you for the tip. I'll try it out, but most likely I'll do the scheduled task, just because I have to recreate symlinks anyway on many stations.
You guys rock!