Closed Bug 381033 Opened 19 years ago Closed 17 years ago

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

Categories

(Firefox :: Installer, defect)

Product:
Firefox
Component:
Installer
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED DUPLICATE of bug 398036

People

(Reporter: whimboo, Assigned: robert.strong.bugs)

References

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?
(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.
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?
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?
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.
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
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!
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.
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
Closed: 17 years ago
Resolution: --- → DUPLICATE
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.
Component: NSIS Installer → Installer
Product: Toolkit → Firefox
You need to log in before you can comment on or make changes to this bug.