Installation fails if files to be written are in use (AccessibleMarshal.dll, MapiProxy.dll, mozMapi32.dll)

VERIFIED DUPLICATE of bug 398036

Status

()

defect
--
critical
VERIFIED DUPLICATE of bug 398036
12 years ago
11 years ago

People

(Reporter: whimboo, Assigned: rstrong)

Tracking

Trunk
x86
Windows XP
Points:
---
Bug Flags:
blocking1.9 -
wanted1.9 +

Firefox Tracking Flags

(Not tracked)

Details

Correlating to bug 380452 which covers AUS we have the same issue for the NSIS installer. It also fails copying new files when they still exist inside the destination folder and are in use by another application. This often happen for MapiProx.dll or mozMapi32.dll while Thunderbird is set as default mail application and users have used MAPI to send a message. Both files are blocked by the initiating application until it is closed.

We have to find a way how to get Toolkit applications installed even if files are in use. Since NSIS v2.01 there is included a new library installation system:

http://nsis.sourceforge.net/Docs/AppendixB.html

Robert, could that be a possible way?
Duplicate of this bug: 378089
Duplicate of this bug: 378198
Duplicate of this bug: 380425
Duplicate of this bug: 374329
Duplicate of this bug: 378037
Duplicate of this bug: 378062
(In reply to comment #0)
> *snip*
> Robert, could that be a possible way?
Sure, it is possible. You will need to require a reboot before the app is run though.
I searched the NSIS forums and found this interesting forum post:
http://forums.winamp.com/showthread.php?postid=2164231#post2164231

Here someone stated that the reboot is only necessary for cleaning up the old files. Dunno if this would help you.
Depends on if the file is already in memory and if it has changed in a way that it would need to be reloaded. Hence why some installers provide the option to reboot after install and why he stated in most cases.
Duplicate of this bug: 382931
Duplicate of this bug: 383244

Comment 12

12 years ago
this may have neen the cause of 2 laptop  total crashes during this time
Can you give more details? Your last comment isn't really helpful. Or don't you have more information about what you have seen?
Duplicate of this bug: 385802
Asking for approval of blocking firefox3. Bug 340535 which handles the automatic update part is already set as blocker.
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3? → blocking1.9?

Comment 16

12 years ago
rstrong, is this something you were looking at as part of the updater in-use fixes?
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]
Not as part of the updater in-use fixes but as a separate fix since NSIS has support for replace on OS restart though it isn't as simple to use due to our packaging requirements in that we place the installer files along side and not inside the installer itself which requires us to use our own hand rolled copy file routines, etc.
A recent addition to the available NSIS plugins allows displaying the application that is using a file. I've verified that it does a pretty damn good job and will investigate further how to best implement this in our Win32 installer and whether to provide an option to install and notify the user that a reboot is required to complete the installation.

http://nsis.sourceforge.net/LockedList_plug-in
Assignee: nobody → robert.bugzilla
Sounds great. Does it also work if another user in background has opened an application? Can we show the user name if needed? It would be nice to have a similar looking UI for the updater which is covered by bug 380452. I'll mark it as depend on this one because we have the initial work here.

I think a switch to assigned should be the right way. ;)
Blocks: 380452
Status: NEW → ASSIGNED
(In reply to comment #19)
> Sounds great. Does it also work if another user in background has opened an
> application?
Yes

> Can we show the user name if needed?
Not at present and I doubt I'll have time to try to implement that functionality.

> It would be nice to have a
> similar looking UI for the updater which is covered by bug 380452. I'll mark it
> as depend on this one because we have the initial work here.
Well, this will be part of the Win32 installation wizard, the two ui's are nothing alike as well as shouldn't be IMO, and the code will be almost if not entirely different since this is an NSIS plugin so there really is no dependency.

No longer blocks: 380452
Couple Notes:

It turns out that when sending an email via IE ieuser.exe continues to run with MapiProxy.dll still in use even after exiting IE and this is the same whether the email is sent using Thunderbird or Windows Mail. :(

Informing a user as to whether a process is being used by them vs. someone else is going to be a tad tricky.
Duplicate of this bug: 404082
Duplicate of this bug: 404278
Flags: wanted1.9+
Whiteboard: [wanted-1.9]

Comment 24

11 years ago
Given that this situation is critical, it would help if you could change the message to suggest some of the possible specific causes...Found this on the web: 

"Kill Quickcam10.exe using the task manager."

I followed this advice and the install worked fine. Never would have guessed this in a million years!

Updated

11 years ago
Duplicate of this bug: 431836

Comment 26

11 years ago
Confirmed, Quickcam is one of the culprits.
(SeaMonkey 2-pre here)

Problem is that you cannot use Quickcam v11+ without having XP, so Win2K users (who just use the OS because it "just works" {tm}) are out of luck here.

Updated

11 years ago
Duplicate of this bug: 431877
Duplicate of this bug: 438636
Bug 398036 fixed this for Firefox so duping this to Bug 398036
Bug 404609 fixed this for Thunderbird
Other apps can implement this using the patches from those bugs as a guide
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 398036
Robert, is this really a dupe of bug 398036? I filed that bug more with the focus of bug 340535. And yesterday you have created bug 452162 and attached a patch to lessen the errors which makes me still think this bug is valid. The patch on bug 452162 only fixes a part of things we need here. Any reconsideration?
Henrik, it is clear that you don't understand which is fine so I will try to explain it to you. Also, please keep in mind that things aren't as clear cut or black and white as everyone would like.

This bug is for the installer... per comment #29)
> Bug 398036 fixed this for Firefox so duping this to Bug 398036
> Bug 404609 fixed this for Thunderbird
> Other apps can implement this using the patches from those bugs as a guide

Also, as far as Thunderbird's installer is concerned this bug is fixed even without Bug 452162 since that bug is to register a copy of the dll's so it won't be in use during an application update. During an install if the dll's are in use the Thunderbird installer will just require a reboot the same as the Firefox installer does.

Does that answer your question in regards to the installer bug where it could not install a file that was in use? It really should. If it doesn't, please try to reproduce this bug where the files you listed are in use.

As for bug 340535, Thunderbird uses MAPI and MAPI does not unload immediately after use which is why application updates for Thunderbird fail MUCH MORE often than they do for Firefox even though there are many more Firefox users... hence why there are more reports from Thunderbird users.

Even if bug 340535 is fixed I don't want the fix to end up causing a significant percentage of Thunderbird users having to reboot after an application update which is what Bug 452162 is mainly about. It will use essentially the same methodology as the really old code did which is to register a copy of the dll's (actually the old code only did this with one dll). The Thunderbird component is the installer because that is where all of the work to make this happen will occur because we need to register the copies of the dll's on install and post update with the post update executable being the helper.exe which is also the uninstaller.

So please tell me how this bug isn't fixed?
Ok, thanks for the explanation. That looks fine.

But sadly there was filed a new bug instead of using an existing one. It seems that you have lost track of of this one. :/

=> Verfied.
Status: RESOLVED → VERIFIED
(In reply to comment #32)
> Ok, thanks for the explanation. That looks fine.
> 
> But sadly there was filed a new bug instead of using an existing one. It seems
> that you have lost track of of this one. :/
Nothing sad about it... it allowed me to concentrate on the actual work that needed to be done.
You need to log in before you can comment on or make changes to this bug.