Closed Bug 760818 Opened 8 years ago Closed 8 years ago

Updating Nightly fails

Categories

(Toolkit :: Application Update, defect)

x86
Windows Vista
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 760577

People

(Reporter: smaug, Unassigned)

References

Details

Attachments

(4 files, 2 obsolete files)

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
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 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.
I ended up removing updated/ folder and re-installing manually to c:\Program files\Nightly
That works too, cool.
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.
Blocks: bgupdates
Also, this is probably a dupe of bug 760027 which has been fixed in the 06/02 Nightly as well.
Whiteboard: [dupe of bug 760027]
Still not fixed x64
(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?
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.
*that was from the 3rd not 2nd.
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!
Attached image Processes for Nightly x64 (obsolete) —
Done, Im going to do a  manual update to the latest nightly and will report tomorrow if it updates successfully.
Still have error with 6/4 nightly auto-update. Adding images now.
Attached image error
Attached image process explorer log
Attachment #630040 - Attachment is obsolete: true
Attachment #629911 - Attachment is obsolete: true
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?
(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.)
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
(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.
(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.
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?)?
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.
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... :)
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.  :-)
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!
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Whiteboard: [dupe of bug 760027]
Duplicate of bug: 760577
You need to log in before you can comment on or make changes to this bug.