452162 - Lessen the number of cases where a restart is required on application update (mozMapi32.dll and MapiProxy.dll)

Status: VERIFIED FIXED

(Thunderbird :: Installer, defect)

Description

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

Spinoff of Bug 340535 comment #234 to lessen how often application update will require a restart to complete once Bug 340535 is fixed.

This can be done by:
a) making a copy of mozMapi32.dll (is that the main culprit?) during install / after update and adding the copy to the registry instead.
b) check in the binary files that seldom if ever change so they aren't recompiled.

Comment 1

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

Attachment: Untested patch in progress (only handles mozMapi32.dll

Comment 2

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

Mark and David, something along the lines of the attached patch should help enormously.

Comment 3

[David :Bienvenu]

Rob, that would be really great; thx a lot for working on this!

Comment 4

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

Attachment: patch

This should lessen the number of people running into this enormously

I'd like a couple of eyes reviewing this change so I am going to request review from both Mark and David

Comment 5

[David :Bienvenu]

Comment on attachment 335475 [details] [diff] [review]
patch

so this looks OK to me, but I'm not at all familiar with the ins and outs of the installer/uninstaller.

Comment 6

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

Comment on attachment 335475 [details] [diff] [review]
patch

This seems to take care of the majority of cases where a reboot is necessary on app update. I'm going to make the patch a bit more robust for edgecases we might run into and resubmit.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Robert, so what happens for applications which want to use this API *after* we have upgraded? Which DLL they are trying to access? The renamed one or the new one? Is the new version of Thunderbird called correctly? Your patch is for the NSIS installer, so does it also apply for AUS?

Comment 8

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

(In reply to comment #7)
> Robert, so what happens for applications which want to use this API *after* we
> have upgraded?
1. If it is already in memory it will use the one in memory... if not, then it will load it into memory and then use it... typical windows dll usage.

> Which DLL they are trying to access?
2. The one defined in the registry.

> The renamed one or the new
> one?
See 1

> Is the new version of Thunderbird called correctly?
Per David these files seldom change and shouldn't change significantly if they do in the future... also, the interfaces on these dll's shouldn't change.

> Your patch is for the
> NSIS installer, so does it also apply for AUS?
Nope, hence why it is in the installer component.

Henrik, can I ask what you are going to do with the answers to these questions?

Comment 9

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

Attachment: patch rev2

Still need to figure out the best approach to dealing with a pending delete of either the MapiProxy_InUse.dll or the mozMapi32_InUse.dll.moz-delete for the PostUpdate case... the rest is pretty much done

Comment 10

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

Attachment: patch rev3

This should do it

Comment 11

[Mark Banner (:standard8)]

Comment on attachment 335507 [details] [diff] [review]
patch rev3

This looks like a good plan. I can't see any problems with it, let's get it out there and test it.

Comment 12

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

Pushed to comm-central
http://hg.mozilla.org/comm-central/rev/bbfb7a098337

Comment 13

[Robert Kaiser]

Does SeaMonkey need something like this as well?

Comment 14

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

(In reply to comment #13)
> Does SeaMonkey need something like this as well?
If all goes as planned with this patch I recommend that SeaMonkey implement this as well. Frank Wein sent me an email last night regarding updating the SeaMonkey installer and I pointed him to this bug as something to also add.

Comment 15

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

I just verified that this fixes the in use issues with the MapiProxy.dll during software update. A MapiProxy_InUse.dll.moz-delete is created in the install dir and is deleted on OS restart. The same should also be true for the mozMapi32.dll. I'm going to keep a close eye on this and hope others do as well.

Comment 16

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

This has caused lots of problems for Thunderbird and I think this should block the next branch release of Thunderbird... at the very least it should be wanted.

Comment 18

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Robert, this bug is marked as blocking1.8.1.18. Do you have to write a new patch or what's the current status to get it fixed for Thunderbird 2.0.0.18?

Comment 19

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

Henrik, a new patch will need to be written... the current status is that I am working on 3.1 bugs and do not know right now when I will get to this.

Comment 70

[Don Moldover]

How can I tell if the update ran successfully when the version returned under 'Help' indicates the same version number that I see in the message indicating that I have an outstanding update to apply?

Comment 72

[floydr69]

Please don't say it is fixed when it is not. I just did The update tonight and had to rename mozmapi32.dll once again. this is getting old.
 The simplest way around this is when the auto update fails go to mozilla thunderbird/mozmapi32.dll and rename it oldmozmapi32.dll, I have 2 or 3 different of mozmapi32.dll in the directory. g You might even have to rename mapiproxy.dll but i have never had to. I believe this is an installer/autoupdate problem and not a bug. but since i can't write a script I can't help there.
 thank you
floyd b

Comment 73

[Henrik Skupin [:whimboo][⌚️UTC+2]]

The patch on this bug only fixes the bits for Thunderbird 3 which is still in development. For Thunderbird 2.0.0.x it isn't fixed yet and as Robert says in comment 19 he doesn't know when he has time for.

Comment 74

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Due to a huge amount of people are affected by this bug we should raise the severity at least to major.

Comment 75

[Aharon Eviatar]

This is definitely not an acceptable fix.  I ran into this problem yesterday and solved it by temporarily disabling my QuickCam.  No ordinary user should be called upon to mess around with the .dll files and it is most user unfriendly to continue to send out the unwanted updates until it is fixed.  I most strongly suggest that you hold off with all imposed updates until you fix the problem.  Much as I dislike MS software, I am a third of the way to Outlook.
Aharon Eviatar

Comment 76

[floydr69]

I believe that You don't start developing a new product when the old one is flawwed unless fatally flawwed,  Is that what the thunderbird developers are saying here? I know it happens all the time in the software/computer industry. This should be a simple bug to fix. it is not in the program. It is in the autoupate script.  
1. do you want to update thunderbird (yes) (no)
 IF yes close all thunderbird applications.  IF no continue running thunderbird.
2 Goto mozilla thunderbird/ mozmapi32.dll remame to oldmozmapi32.dll
3 Goto mozilla thunderbird/ mapiproxy.dll remame to oldmapiproxy.dll
4 install update
if you run into this problem selecting no on the update only delays the problem til you start thunderbird again it will update then
 many people have said this is getting tiring
floyd

Comment 78

[Auro kena]

while l agree this is still a annoying update bug, lve never renamed the offending files.. the strange part is it seems my webcam is using the offending process...

my method of getting around the issue is downloading a program called unlocker from here (http://ccollomb.free.fr/unlocker/) which adds a new context menu on right click over folders and files (all files) clicking the unlocker option will provide options to kill "all" or specific processes in my case the offending file is mozMapi32.dll after killing that process manually it works perfectly.

(another person who is suffering the same issue as Aharon Eviatar)

usually l would download manually for updates but since my thunderbird is open 24/7 is makes installing annoying at least if l didnt have unlocker.

Comment 79

[d.mthomas]

I solved the immediate problem by downloading 17 and installing in a different directory. However, I still have the old system and can't remove it using Windows uninstall.
Doug

Comment 80

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

(In reply to comment #72)
floydr69, this has only been fixed on the trunk for Thunderbird 3.0

(In reply to comment #75)
Aharon Eviatar, this has only been fixed on the trunk for Thunderbird 3.0 and users do not need to mess with dll files.

(In reply to comment #76)
floydr69, see my previous reply and if you'd like to write a patch to fix this for Thunderbird 2.x feel free to do so. At this time I am very busy with fixing bugs for Firefox 3.1 and I am not sure when I will have time to write a patch for Thunderbird 2.x.

(In reply to comment #78)
Auro kena, when Thunderbird 3.0 is released or if you are using Thunderbird trunk nightly you will no longer need to do this... hurrah!

(In reply to comment #79)
> I solved the immediate problem by downloading 17 and installing in a different
> directory. However, I still have the old system and can't remove it using
> Windows uninstall.
Setting the new install as the default mail app and restarting the computer should allow you to remove the old install with Windows uninstall.

Comment 81

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #80)
> bugs for Firefox 3.1 and I am not sure when I will have time to write a patch
> for Thunderbird 2.x.

Mark and David, are there any free resources on the Mozilla Messaging side to help out and fix the issue for users of Thunderbird 2?

Comment 82

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Verified fix on trunk by upgrading the nightly build from 08091307 to 08092803.

Comment 83

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

Per comment #19 I won't have the time to write a 1.8.1.x patch for this so reassigning to default. Please feel free to take this bug.

Comment 85

[Daniel Veditz [:dveditz]]

Assigning to dmose for Tbird team triage. We marked this blocking optimistically since there was a trunk patch and this is a big support issue (over 50 dupes), but it looks like someone from the Thunderbird team would have to do the back-port.

Comment 86

[Dan Mosedale (:dmosedale, :dmose)]

Standard8 has agreed to take a run at this.

Comment 87

[Frank Wein [:mcsmurf]]

Attachment: 1.8 Branch patch (not complete)

This is Attachment 335507 [details] [diff] ported to the 1.8 branch. But(!) it is not complete yet, the part that is missing are the changes to the PushFilesToCheck macro. That one checks if files are in use during install/uninstall and asks the user to close the application. That was only implemented on trunk though, see Bug 398036. Not sure what to do here as I don't know when the MapiProxy.dll file is in use and when a restart is required then...

Comment 88

[floydr69]

The bug I reported Did NOT require a restart  It was in a continous loop because the mozmapi32.dll was not correctly updated plain and simple. I was able to fix it everytime there has been a major update to thunderbird v2 by renaming mozmapi32.dll.  if someone would write an installer that would rename the offending files mozmap32.dll and mapiproxy.dll I believe all would be good.
I am not sure if they are included in the updates if not, after update is finished perhaps rename them back?
If thunderbird behaves the same way on all win vista systems it has to be shut down when updating. 
I am not a programer or i would have tackled this long ago. years ago a installer script could have been written to take care of this. 
 later
floyd

Comment 89

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

floydr69, the word "restart" in relation to this bug has to do with the typical way of handling a file in use on windows in that there are windows api's for copying a file over an existing file in use during the OS restart. The patch that has landed on the trunk what you are requesting.

Comment 90

[floydr69]

thankyou, still doesn't make sense to me as my windows vista doesn't restart on the installation of the update of thunderbird v2, if it is fixed ok. have a good night
later floyd

Comment 93

[Samuel Sidler (old account; do not CC)]

Talked this over with Mark. This isn't going to make 1.8.1.19. We'll take it in the next Thunderbird release.

Comment 97

[Steve Anderson]

Grr, I just spent over an hour tracking this down.  It seems to me that an install bug that takes a working email program and turns it into an infinite loop of update errors would be a stop-ship.  I wonder how many users are being affected currently that are not programmers, and have no idea how to get back their email.

I tried rebooting, I tried reinstalling from a fresh download, and I tried manually deleting mozMapi32.dll, none of which worked.  Finally I find this thread, only after logging my own bug and having it marked as a dupe of this one.  (The title of this is really unhelpful.)

Now I seem to be able to run Thunderbird, but it's not reaching any of my servers for email.  <Sigh>, more hacking...

Comment 98

[Steve Anderson]

Aha, I needed to un-rename those two files.  Done, and functional again.

Comment 104

[Aharon Eviatar]

I again have had to jump through the hoop of renaming two dll files in order to install an update for which I have no real need nor interest.  This is becoming tiresome since I have better things to do with my time and computer.  I suggest you stop generating updates and do something serious to crush this bug.

Comment 105

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #87)
> Created an attachment (id=343693) [details]
> 1.8 Branch patch (not complete)
> 
> This is Attachment 335507 [details] [diff] ported to the 1.8 branch. But(!) it is not complete
> yet, the part that is missing are the changes to the PushFilesToCheck macro.
> That one checks if files are in use during install/uninstall and asks the user
> to close the application. That was only implemented on trunk though, see Bug
> 398036. Not sure what to do here as I don't know when the MapiProxy.dll file is
> in use and when a restart is required then...

Robert, can you give a helpful comment so Frank will know what to do to probably fix the problem on 1.8 branch?

Comment 106

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

(In reply to comment #105)
> (In reply to comment #87)
> > Created an attachment (id=343693) [details] [details]
> > 1.8 Branch patch (not complete)
> > 
> > This is Attachment 335507 [details] [diff] [details] ported to the 1.8 branch. But(!) it is not complete
> > yet, the part that is missing are the changes to the PushFilesToCheck macro.
> > That one checks if files are in use during install/uninstall and asks the user
> > to close the application. That was only implemented on trunk though, see Bug
> > 398036. Not sure what to do here as I don't know when the MapiProxy.dll file is
> > in use and when a restart is required then...
> 
> Robert, can you give a helpful comment so Frank will know what to do to
> probably fix the problem on 1.8 branch?

Any macros in common.nsh that don't exist on the 1.8 branch can be added to shared.nsh. I believe I also talked with Frank on IRC about the dll reg entries that would need to be added which I am unsure of a decent approach and is the more difficult aspect of fixing this on the branch.

Comment 108

[Susan S]

I'm new here and tried the fix of:
2 Goto mozilla thunderbird/ mozmapi32.dll remame to oldmozmapi32.dll
3 Goto mozilla thunderbird/ mapiproxy.dll remame to oldmapiproxy.dllz

Then tried to install my old copy of Thunderbird "Thunderbird Setup 2.0.0.6.exe" and got further but then ran into the problem that "extensions/talkback.exe" wouldn't write.

This is very frustrating.  I use Thunderbird for my business email and have all my addresses in the Address Book, which I can't access it now.

I'm a user with a limited knowledge of application innards.  I was originally trying to update Thunderbird 2.0.1.8.

Comment 109

[Mike]

Problem has been fixed by my dauther

Comment 110

[Magnus Melin [:mkmelin]]

Susan: if you've got a logitech quickcam, disabling it should do the trick.

Otherwise, if you've renamed the dlls, reboot and install 2.0.0.18 into another empty folder.

Comment 115

[Robert Warner]

Ok, yes after disabling the logitech quick cam this solved the problem.  But i do not see how this is marked as fixed.  Shouldn't the installer check for the logitec quick cam and force it to shutdown or tell the user to turn it off prior to install?

Comment 116

[Mark Banner (:standard8)]

(In reply to comment #115)
> Ok, yes after disabling the logitech quick cam this solved the problem.  But i
> do not see how this is marked as fixed.

The way we manage our bugs is that they get marked fixed once they are fixed on trunk (i.e. for the next major release), status on branches is handled via keyword flags.

If you read the whiteboard and the comments you will see that this has been fixed for the Thunderbird 3 builds (aka "trunk"). I'm hoping to be able to spend some time this week to do the back-porting to Thunderbird 2 builds (aka "1.8 branch").

Comment 118

[Wheat Williams]

The same bug is still present in Thunderbird 2.0.0.17 through 2.0.19.

My client has an HP notebook with a webcam and Logitech quickcam.exe loaded at startup.

Updates always fail when quickcam.exe process is running, saying that mozMapi32.dll cannot be replaced because it is locked or in use. This is the same with auto-update from the previous point release, or if using the stand-alone installer of the latest version.

Quitting the quickcam.exe process enables the update to be run successfully.

Comment 119

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Wheat, there is no fix checked in for Thunderbird 2.0.0.x yet. You have to wait and use this workaround until you upgrade to Thunderbird 3.0 some day after it was getting released.

Comment 126

[Samuel Sidler (old account; do not CC)]

Mark, any update on this? This is the top reported issue in Thunderbird 2.0.0.21.

Comment 127

[glennc]

I submitted bug 484444 and can confirm that the update failure only occurred 
on the one system where a logitech quickcam 9000 had just been installed before
the update.  Uninstalling the quickcam allowed the update to work (did
that before seeing the reports).  The very concerning thing for users
is the endless loop with no exit and the loss of email access.  Even if
a message was generated about the error and fix, and allowing the 
canceling of the install attempt this would significantly reduce the
concern for users.

Comment 128

[Aharon Eviatar]

After a few months of quiet from the Mozilla bug, again I had to jump through the hoops again, renaming the dll files etc.  I am not a computer geek, just a working physicist and this has become a major irritant.  I hope this issue can be resolved in a finite time.  I understand my version 2.0 something is still buggy.

Comment 130

[David]

I appreciate all the work you guys are doing to fix the bug, but I am not as confident in the reliability of Thundetbird as I once was. I can't afford to lose my email for more than 24 hours, and I have to have the confidence to know that if something happens, I can still access it via other means! If I weren't somewhat computer literate, would I have known to post to a specific Forum to get my email back and running? It makes me want to bite my fingernails again.

Anyway, thanks for the good work! I will remain a loyal Thunderbird bird!
D

Comment 132

[Frank Wein [:mcsmurf]]

Attachment: 1.8 Branch patch

Ok, this should do it. I tested this patch locally by: First installing a new Thunderbird build with this patch, then sending a mail via the "Send To" context menu in explorer (this will keep a file lock on MapiProxy_InUse.dll) and then installing a new Thunderbird build with this installer. After it finished copying the files, I got a dialog page asking me to reboot. The downside of this patch is that it would only fix things in the next but one version of Thunderbird 2.0.0.x (when the file is in use at the time the installer is running) as the installer first needs to register MapiProxy_InUse.dll once and then the installer magic can depend on that.

Comment 133

[Frank Wein [:mcsmurf]]

Attachment: Dialog page for reboot

Comment 134

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

Comment on attachment 372021 [details] [diff] [review]
1.8 Branch patch

The Shell Integration code will either need to be taught to register mozMapi32_InUse.dll or hand it off to the helper.exe to register it as is done on trunk.

Comment 135

[Frank Wein [:mcsmurf]]

Comment on attachment 372021 [details] [diff] [review]
1.8 Branch patch

>@@ -161,7 +164,7 @@
> !macro SetClientsMail
>   GetFullPathName $8 "$INSTDIR\${FileMainEXE}"
>   GetFullPathName $7 "$INSTDIR\uninstall\helper.exe"
>-  GetFullPathName $6 "$INSTDIR\mozMapi32.dll"
>+  GetFullPathName $6 "$INSTDIR\mozMapi32_InUse.dll"

This does change helper.exe...? Or do you mean we need to force updating HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Mail\Mozilla Thunderbird\DLLPath in the installer so that things work like they should?

Comment 136

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

I haven't looked at it in a while but the shell integration code registers at least the mapi proxy... it might not do anything with mozMapi32 but I wouldn't be surprised if it does. This is the part I didn't have time to work on. :(
http://mxr.mozilla.org/mozilla1.8/source/mail/components/shell/nsMailWinIntegration.cpp#457

Comment 137

[Frank Wein [:mcsmurf]]

Oh, I see. Looked at the wrong tree in mxr :|

Comment 138

[Frank Wein [:mcsmurf]]

Attachment: Patch

Not a very pretty patch, but this way it should work. I looked into the xpinstall installer, but I saw no easy way to copy MapiProxy.dll to MapiProxy_InUse.dll and avoid rebooting/file locking issue (I do not know how the xpinstall installer currently handles this and I would like to keep the branch patch rather minimal). Just packaging MapiProxy_InUse.dll would not work as then we would have the old state again (file in use and installer stumbles over this when copying the files).

Comment 139

[Mark Banner (:standard8)]

Comment on attachment 372050 [details] [diff] [review]
Patch

This is basically a slightly reduced port of the trunk patch. Whilst I couldn't reproduce the failures with my current setup I'm confident that this should fix the issue - being a port of the trunk fix. I also checked that the address book mapi interface still worked correctly.

r=me. Requesting 1.8.1 branch approval, would be good to get a few folks testing this before the next release.

Comment 140

[Dan Mosedale (:dmosedale, :dmose)]

Approving for branch.  Mark, you've demonstrated good judgement doing trunk driving and here; I don't think requiring me to approve stuff that you've decided is sensible to land adds value.  As a result, I'd support you just feeling free to approve mailnews bugs for the branch, assuming ss and dveditz don't have an issue with it.

Comment 141

[Samuel Sidler (old account; do not CC)]

Comment on attachment 372050 [details] [diff] [review]
Patch

Since we're not freezing for the next Thunderbird release for another three or four weeks, I'd like to hold off on approving this.

I asked Rob to run some manual tests on this since he debugged and fixed the problem for Firefox.

Comment 142

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

(In reply to comment #141)
> (From update of attachment 372050 [details] [diff] [review])
> Since we're not freezing for the next Thunderbird release for another three or
> four weeks, I'd like to hold off on approving this.
I'll try to do this sometime in the next week

> I asked Rob to run some manual tests on this since he debugged and fixed the
> problem for Firefox.
s/Firefox/Thunderbird Trunk/

Comment 143

[Frank Wein [:mcsmurf]]

A way to reproduce this bug with a normal setup without a Logitech webcam or such is: Set Thunderbird as default mail app, now right click on any file in Windows explorer and send it via "Send To"->"Mail Recipient". This will lock the MapiProxy.dll file (you can still rename that file though!). When you now try to install a new Thunderbird version (with or without the patch), the problem should still occur. Now you need to set Thunderbird once as default mail application again and on the next installation of a new Thunderbird version the problem should no longer occur.
Now that I think about it, maybe we should force registration of the mapi dll and update the DLLPath key below Software\Clients\Mail\Mozilla Thunderbird if Thunderbird is currently the default mail application? Normally Thunderbird will already be the default mail app after updating, so it would not register and update those registry entries with the current patch.

Comment 144

[Frank Wein [:mcsmurf]]

(In reply to comment #143)
> Now that I think about it, maybe we should force registration of the mapi dll
> and update the DLLPath key below Software\Clients\Mail\Mozilla Thunderbird if
> Thunderbird is currently the default mail application?

I meant "if the current installation location matches the path inside DLLPath".

Comment 145

[Frank Wein [:mcsmurf]]

Ok, ignore the update DLLPath part, we already do that via calling SetClientsMail on every install and update.

Comment 146

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

When running helper.exe /SetAsDefaultAppGlobal the Clients\Mail\Mozilla Thunderbird DLLPath registry key is created with an empty string as a value.

Comment 147

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

Comment #146 is likely an edgecase.

Comment 148

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

Everything behaves well. The only comment I have is that SetAsDefaultAppGlobal should probably copy MapiProxy.dll to MapiProxy_InUse.dll and mozMapi32.dll to mozMapi32_InUse.dll but that shouldn't be an issue for the branch and should be done in a followup for the trunk

Comment 149

[Samuel Sidler (old account; do not CC)]

Comment on attachment 372050 [details] [diff] [review]
Patch

Thanks for testing Rob.

Approved for 1.8.1.22. a=ss

Comment 151

[Frank Wein [:mcsmurf]]

Checking in mail/installer/windows/nsis//installer.nsi;
/cvsroot/mozilla/mail/installer/windows/nsis/installer.nsi,v  <--  installer.nsi

new revision: 1.1.2.14; previous revision: 1.1.2.13
done
Checking in mail/installer/windows/nsis//shared.nsh;
/cvsroot/mozilla/mail/installer/windows/nsis/shared.nsh,v  <--  shared.nsh
new revision: 1.2.2.6; previous revision: 1.2.2.5
done
Checking in mail/installer/windows/nsis//uninstaller.nsi;
/cvsroot/mozilla/mail/installer/windows/nsis/uninstaller.nsi,v  <--  uninstaller
.nsi
new revision: 1.1.2.7; previous revision: 1.1.2.6
done

Comment 152

[Al Billings [:abillings - ex-MoCo]]

I just tried this with last night's nightly 1.8.1 build after following the steps comment #143. With that build (and with the Thunderbird 2.0.0.21 build), once the install starts, I receive an error message stating "Error opening file for writing: C:\Program Files\Mozilla Thunderbird\MapiProxy.dll Click Retry to try again, Cancel to stop installation."

My understanding is that I shouldn't see this error message with the nightly 1.8.1 build since this was fixed four days ago so this does not look fixed for 1.8.1.

Comment 153

[Al Billings [:abillings - ex-MoCo]]

After talking to Frank, this only works if you are upgrading *from* a build with a fix.

So I tried upgrading from the 6/1 build (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.22pre) Gecko/2009060103 Thunderbird/2.0.0.22pre) to the 6/2 build on Windows XP using the steps in comment #143. I still receive the same error message when I upgrade though.

This looks like it isn't fixed.

Comment 154

[Frank Wein [:mcsmurf]]

Ok, my fault. Should be fixed in the next nightly.
Checking in mailnews/mapi/mapihook/src/Registry.cpp;
/cvsroot/mozilla/mailnews/mapi/mapihook/src/Registry.cpp,v  <--  Registry.cpp
new revision: 1.3.152.1; previous revision: 1.3
done

Comment 155

[Samuel Sidler (old account; do not CC)]

Typically, unless you're fixing some sort of bustage that's made the tinderboxen red, you should attach a patch and get review and approval for your follow ups, per the tree rules.

For reference, here's the diff: http://bonsai.mozilla.org/cvsview2.cgi?command=DIFF&subdir=mozilla%2Fmailnews%2Fmapi%2Fmapihook%2Fsrc&file=Registry.cpp&rev1=1.3&rev2=1.3.152.1&whitespace_mode=show&diff_mode=context

Comment 156

[Mark Banner (:standard8)]

(In reply to comment #155)
> Typically, unless you're fixing some sort of bustage that's made the
> tinderboxen red, you should attach a patch and get review and approval for your
> follow ups, per the tree rules.
> 
> For reference, here's the diff:
> http://bonsai.mozilla.org/cvsview2.cgi?command=DIFF&subdir=mozilla%2Fmailnews%2Fmapi%2Fmapihook%2Fsrc&file=Registry.cpp&rev1=1.3&rev2=1.3.152.1&whitespace_mode=show&diff_mode=context

In Frank's defence, that diff was in the original patch, looks like it just got missed on initial checkin.

Comment 157

[Al Billings [:abillings - ex-MoCo]]

Verified for 1.8.1.22 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.22pre) Gecko/2009060404 Thunderbird/2.0.0.22pre and the build from 6/3.

Comment 160

[glennc]

Unfortunately this problem has reoccurred with the current update on a 
computer with a new logitech webcam installation.  Had to go the old 
mozmapi32.dll remame to oldmozmapi32.dll 
route to get it working again during the endless loop 

glennc

Comment 161

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

glennc, the fix has to first be applied by upgrading and from that point forward future updates should work without experiencing this bug.

Comment 162

[Aharon Eviatar]

Verified fixed my $%&$%^&!  I just had to do the renaming gig again to get Thunderbird to work.  If it is working, why the unnecessary upgrades?   If it ain't broke don't fix it.
Aharon

Comment 163

[Mark Banner (:standard8)]

(In reply to comment #162)
> Verified fixed my $%&$%^&!  I just had to do the renaming gig again to get
> Thunderbird to work.  If it is working, why the unnecessary upgrades?   If it
> ain't broke don't fix it.
> Aharon

Upgrades are provided to fix any security issues that have been discovered and sometimes to improve stability as well.

This bug *is* fixed. However, due to the way the updating process works, you must first download the version which contains the fix (2.0.0.22) and install it before the fix will work. When the *next* upgrade comes out the fix will already be installed and there should be no repeat of this bug.

Comment 166

[Brian Cupp]

This fix has caused the MAPI function within Windows XP to not function any more when using Thunderbird 2.0.0.22. Thunderbird 2.0.0.21 did not have this problem.

Comment 167

[Dan Mosedale (:dmosedale, :dmose)]

Brian, if you could file a new bug on that with specific steps to reproduce and mark it as blocking this bug, that would be very helpful.

Comment 168

[Magnus Melin [:mkmelin]]

Bug 499958, which seems to be going for some record in amount of dupes?

Comment 169

[Brian Cupp]

The Bug I reported in Comment #166 has been reported and is https://bugzilla.mozilla.org/show_bug.cgi?id=499958