380452 - Updater needs a process window to list applications which block files to be patched (AccessibleMarshal.dll, MapiProxy.dll, mozMapi32.dll)

Status: RESOLVED WONTFIX

(Toolkit :: Application Update, enhancement)

Description

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

Currently the update process fails if any file which has to be patched is in use by another application. The update process stops and starts the former version of Thunderbird or loops infinitely (bug 340535).

To prevent this behavior we should integrate a process window which shows all processes which block our files. The user is able to identify and close the applications before he continues the update process. Therefor two buttons should exist: Repeat and Cancel.

This feature is already implemented in a bunch of different applications. I already saw several one on Windows. It would be great to have the same feature for Firefox and Thunderbird. A lot of people will be glad to see why the update process isn't finished correctly.

Comment 1

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

Robert, would that be a different kind as the Installer or can both utilize from this feature?

I know that the installer is based on the Nullsoft Installer. Hasn't that one such a check already implemented but we don't use it actually?

Comment 2

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

(In reply to comment #1)
> Robert, would that be a different kind as the Installer or can both utilize
> from this feature?
The updater.exe would have to implement it itself.
 
> I know that the installer is based on the Nullsoft Installer. Hasn't that one
> such a check already implemented but we don't use it actually?
It has a replace file on OS reboot which we don't use at present and we are planning on using a different methodology due to several issues regarding multiple users using the same app at the time of upgrade.

Comment 3

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

(In reply to comment #2)
> > Robert, would that be a different kind as the Installer or can both utilize
> > from this feature?
> The updater.exe would have to implement it itself.

So this bug is only for Software Update.

> It has a replace file on OS reboot which we don't use at present and we are
> planning on using a different methodology due to several issues regarding
> multiple users using the same app at the time of upgrade.
 
Is there already a bug about that issue? There are several bugs which are wrongly duped against 340535 and I would correct. If not, I could file a new bug report therefor.

Comment 5

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

I filed bug 381033 for the NSIS installer issue.

Comment 7

[Skewer]

As this blocks a critical issue, this should also be a critical issue.

Comment 8

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

It's not a crasher, data loss, or memory leak issue. It's even not existent at the moment, so changing severity to enhancement.

Mike, do you think that we have a possibility to get this implemented for Firefox 3?

Comment 9

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

btw: if the person updating doesn't have admin priv's and another user is responsible for the file in use we won't be able to show the process responsible.

Comment 10

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

(In reply to comment #9)
> btw: if the person updating doesn't have admin priv's and another user is
> responsible for the file in use we won't be able to show the process
> responsible.

That's true. In that case we should at least give some general information that this file is blocked by another process and a restart is necessary before the update can be applied.

Comment 11

[Benjamin Smedberg]

Robstrong, how *do* you know the process responsible? I've been wanting that data for the profile-locked dialog for a long time, and didn't think there was a way to get it.

Comment 12

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

I personally have never tried so I haven't a clue. The point is that even if we found a way that doing so without rights to do so is not possible.

Comment 13

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

Benjamin, there is the listdlls tool from sysinternals which gives you a list of processes holding a handle to a specified module. It's really interesting and helped me a lot of times. So as they can get the processes there should be a way of doing that.

http://www.microsoft.com/technet/sysinternals/utilities/listdlls.mspx

The result for mapiproxy.dll you can see here:

c:\test>listdlls -d mapiproxy.dll

ListDLLs v2.25 - DLL lister for Win9x/NT
Copyright (C) 1997-2004 Mark Russinovich
Sysinternals - www.sysinternals.com

------------------------------------------------------------------------------
TOTALCMD.EXE pid: 1872
Command line: "C:\Programme\Total Commander\TOTALCMD.EXE"

  Base        Size      Version         Path
  0x60140000  0x7000    0.00.0000.0000  c:\Programme\Mozilla Thunderbird 3.0\Map
iProxy.dll

If you are an administrator and another user has such a process you will also see the userid.

Comment 15

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

WhoUses might also be of assistance
http://www.codeguru.com/cpp/w-p/system/processesmodules/article.php/c2827/

Comment 17

[Masatoshi Kimura [:emk]]

WinVista has a documented way to determine who are using files.
See MSDN "Restart Manager" article for details.
http://msdn2.microsoft.com/en-us/library/aa373654(VS.85).aspx
See also:
http://msdn.microsoft.com/msdnmag/issues/07/04/NETMatters/default.aspx?loc=en
If we need to support WinXP or earlier, we will have to dig into something undocumented.

Comment 18

[Todd]

Hi All,

I have a number of XP customer with Logitech's Quick Cam.
Problem: it puts a file lock on Thunderbird's mozMapi32.dll,
effective crashing any attempt to upgrade Thunderbird.

The workaround is to go to icon tray in the task bar
and exit Logitech's Quick Cam.  Them upgrade Thunderbird.

I would be cool if the developers came up with a way to usurpt
file locks when installing/upgrading Thunderbird.

Dump question: would changing the name of mozMapi32 to something
else, so Quick Cam can not find it, help this problem?

Many thanks,
-T

Comment 19

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

That has already been done via bug 452162 though there is a followup in bug 499958 that still needs to be fixed

Comment 20

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

Bug 466778 makes it so the only file in use that will prevent an update is the main application file. I don't think fixing this bug is an appropriate use of time or that the added complexity is worth it. Instead it would be better to focus on preventing this from happening. Resolving -> wontfix.