760818 - Updating Nightly fails

Status: RESOLVED DUPLICATE of bug 760577

(Toolkit :: Application Update, defect)

Description

[Olli Pettay [:smaug]]

Updating Nightly 2012-06-01 to -02 fails.
It seems that update is applied, but when restarting there is
error message complaining that there is already Firefox running.
After closing that dialog and starting Nightly normally, it is still -01, not
-02

Comment 1

[Olli Pettay [:smaug]]

Perhaps this has something to do with the strange installation.
By default installation tried to install to C:\Program Files\Nightly\updated
So I ended up to two different versions. The old one in C:\Program Files\Nightly
new one in C:\Program Files\Nightly\updated

Comment 2

[Brian R. Bondy [:bbondy]]

Comment 1 is a dupe of bug 759615.  If you try to install after an update it would default the install to installdir/updated.  Did you by chance actually install though to the /updated dir? If so I suggest to uninstall the /updated one, then uninstall the installdir one and then re-install.  You can uninstall from the install dir by executing installdir/uninstall/helper.exe.

I think Comment 0 is related to Bug 759615, or having a command prompt open to the install dir while updating which will be fixed by bug 760577.

Comment 3

[Olli Pettay [:smaug]]

I ended up removing updated/ folder and re-installing manually to c:\Program files\Nightly

Comment 4

[Brian R. Bondy [:bbondy]]

That works too, cool.

Comment 5

[(no longer active)]

Yeah, the fix to bug 759615 is in the 06/02 nightly, which means that it will kick in when you try to update to the next Nightly.  Please let us know if you see this again after the 06/02 nightly.

Comment 6

[(no longer active)]

Also, this is probably a dupe of bug 760027 which has been fixed in the 06/02 Nightly as well.

Comment 7

[chaosfreedom1220]

Still not fixed x64

Comment 8

[(no longer active)]

(In reply to chaosfreedom1220 from comment #7)
> Still not fixed x64

Which version of Nightly are you using?  Can you please provide a copy of your last-update.log file?

Comment 9

[chaosfreedom1220]

Attachment: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:15.0) Gecko/15.0 Firefox/15.0a1 6/2/12 Build Update log

This file is located in both a /updates and /updated folder and subfolders of the same name in both files. Every time there is a new  update downloaded with the auto-updater a new folder is added within the folders and it continues to fail. Uninstall everything and it repeats this process of creating subfolders and never updating.

Comment 10

[chaosfreedom1220]

*that was from the 3rd not 2nd.

Comment 11

[(no longer active)]

Can you please do the following:

1. Download and run Process Explorer <http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx>.
2. From the Find menu, click Find Handle or DLL.
3. In the Handle or DLL substring field, type in the full path to your Firefox installation directory, and see which process is holding a handle to the directory itself.  A screenshot of that dialog would be super helpful.

Thanks!

Comment 12

[chaosfreedom1220]

Attachment: Processes for Nightly x64

Comment 13

[chaosfreedom1220]

Done, Im going to do a  manual update to the latest nightly and will report tomorrow if it updates successfully.

Comment 14

[chaosfreedom1220]

Still have error with 6/4 nightly auto-update. Adding images now.

Comment 15

[chaosfreedom1220]

Attachment: error

Comment 16

[chaosfreedom1220]

Attachment: process explorer log

Comment 17

[chaosfreedom1220]

Attachment: last-update log 6/4 x64

Comment 18

[chaosfreedom1220]

Attachment: image of processes for Night/Updates folder

Comment 19

[chaosfreedom1220]

Added image of the results of process explorer for the nightly\updated folder. That might be the issue right there as it targets explorer.exe instead of firefox.exe in the nightly folder?

Comment 20

[(no longer active)]

(In reply to chaosfreedom1220 from comment #19)
> Added image of the results of process explorer for the nightly\updated
> folder. That might be the issue right there as it targets explorer.exe
> instead of firefox.exe in the nightly folder?

Yes.  Do you have an Explorer window open showing that folder?  (Note that the work in bug 760577 will make it possible to update even if that directory is locked.)

Comment 21

[Andreas Schoeneck]

I recently started to iscuss the issue on the mailing list, if you wish to have a look at the information I provided there, you may go to:

https://mail.mozilla.org/pipermail/nightly-testers/2012-June/001298.html

Comment 22

[(no longer active)]

(In reply to Andreas Schoeneck from comment #21)
> I recently started to iscuss the issue on the mailing list, if you wish to
> have a look at the information I provided there, you may go to:
> 
> https://mail.mozilla.org/pipermail/nightly-testers/2012-June/001298.html

I'm working to fix this issue in bug 760577.

Comment 23

[Andreas Schoeneck]

(In reply to Ehsan Akhgari [:ehsan] from comment #22)
> I'm working to fix this issue in bug 760577.

Seems to be more like a workaround - would be nice to see why the replace of Firefox install dir fails. However, setting app.update.stage.enabled to false fixes the issues on my machine for the moment.

Comment 24

[Andreas Schoeneck]

Since setting app.update.stage.enabled to false leverages the issue, I guess that bug 760577 actually fixes my issue. The problem is that my Nightly won't update silently.

Should there be put any effort on resolving the cause of the silent update failure (->new bug?)?

Comment 25

[(no longer active)]

The cause is that on Windows it's possible for applications to hold a file or directory open in a way that other applications would not be able to rename it, which is what's happening here.  Bug 760577 works around this problem by applying the update on restart if that happens instead of doing it in the background.  While that will not be silent, it's better than having the update process fail completely.  There isn't too much that we can do to fix the cause since we have no control over all of the applications that the user is running.

Comment 26

[Andreas Schoeneck]

Sorry, Ehsan for possibly bugging you, but the case is that if I close Nightly I am immediately able to successfully rename the directory (from a self-written, unelevated program). Also, I cannot identify any process holding a handle to Nightly directory when updater.exe runs.

To me, these two things indicate that there's a problem with Nightly's infrastructure.
I see the point of cmd.exe, explorer.exe and their buddies holding handles that prevent the Nightly directory from being renamed, but I just don't see such things on my machine.

PS: I also hate bugs on my desk that I do not understand to all extends... :)

Comment 27

[(no longer active)]

So it turns out that if you start Firefox by clicking a shortcut which has the Firefox installation directory set as the working directory, a handle to that directory is kept open and not closed soon enough for us to be able to apply the update.

I respectfully request you to wait for bug 760577 to get fixed (please CC yourself there if you want to get a notification on when it gets marked as RESOLVED FIXED) and report back if you have problems after that bug is fixed.  We currently believe that the patches in that bug should provide an ultimate fallback to fix this problem once and for all.  :-)

Comment 28

[(no longer active)]

Bug 760577 was fixed today.  Please upgrade a Nightly which contains that fix (a Nightly with this fix is ready right now) and reopen this bug if this happens for you again.  Thanks!