1070661 - Error setting access/modification time on application bundle

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[Robert Strong (they/them - no direct email)]

Seen while updating on Oak

Comment 1

[Robert Strong (they/them - no direct email)]

Attachment: patch rev1

Pushed to try
https://tbpl.mozilla.org/?tree=Try&rev=de1388875cf3

Comment 2

[Robert Strong (they/them - no direct email)]

Attachment: patch rev1

Try looks good

Pushed to oak
https://hg.mozilla.org/projects/oak/rev/e12ab67e9f2d

Comment 3

[Stephen A Pohl [:spohl]]

Comment on attachment 8492686 [details] [diff] [review]
patch rev1

Review of attachment 8492686 [details] [diff] [review]:
-----------------------------------------------------------------

Looks great, just this one question below. r=spohl

::: toolkit/mozapps/update/updater/updater.cpp
@@ +2190,5 @@
>  #ifdef XP_MACOSX
> +      // If the update was successful we need to update the timestamp on the
> +      // top-level Mac OS X bundle directory so that Mac OS X's Launch Services
> +      // picks up any major changes when the bundle is updated.
> +      if (!sStagedUpdate && utimes(gInstallDirPath, nullptr) != 0) {

Could you walk me through the steps during a staged update? Will the timestamp be updated upon relaunch of Firefox?

Comment 4

[Robert Strong (they/them - no direct email)]

The update is staged by copying the files in the bundle to the staging directory under ~/Library/caches/...etc. So, the stage copy doesn't need the timestamp updated. When an update is applied directly to the bundle is completed or when a replace request is completed that is when the bundle itself is updated and needs the timestamp updated.

Comment 5

[Stephen A Pohl [:spohl]]

Great, it was the replace request that I was wondering about. Thanks for clarifying!

Comment 6

[Robert Strong (they/them - no direct email)]

Note: the fix won't be seen except when updating with a build that includes this fix so Sunday's nightly (e.g. on Monday) unless another nightly is generated.

Comment 7

[Robert Strong (they/them - no direct email)]

I created an additional nightly yesterday and I verified the patch fixed this bug for the next nightly. No error and the bundle date timestamp had changed.

Comment 8

[Robert Strong (they/them - no direct email)]

Pushed to fx-team
https://hg.mozilla.org/integration/fx-team/rev/1599a302abfb

Comment 9

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/1599a302abfb

Comment 10

[Robert Strong (they/them - no direct email)]

Landed on aurora in the Mac V2 signing combined patch in bug 1047584