624500 - If an app file can't be removed during an upgrade because the file is in use, perhaps display information about applications using it

Status: RESOLVED WONTFIX

(Toolkit :: Application Update, defect)

Description

[Jeff Walden [:Waldo]]

My uncle managed to wedge his Firefox doing a minor update because some software he'd installed, Babylon (some sort of language-translation tool), had loaded mozcrt19.dll (!).  The wedging was basically worst-case: restart for update, get the already-running dialog, click through it, restart again for update, get the already-running dialog, and so on apparently forever, with no exit.

I queried IRC and got pointed at the update log location.  Skimming that it became clear which file was at fault.  Then a little web searching pointed out tasklist /m mozcrt19.dll, from which I was able to figure out the offender.

I have no idea how anyone not connected to the Mozilla community could have figured this out.  But if we displayed information about which applications were using a file, someone might be able to at least stumble through the steps and get something that works again.  The tasklist /m information would have been adequate for me, but maybe there's something better to use.  But it's clear there's more information that could be displayed, which would have a good chance of being useful.

Comment 1

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

I landed bug 466778 on 1.9.2 which should fix the issue as stated. I personally think it is better to spend time on making the update successful 100% of the time vs. reporting on which process / user has a file open. Also, at this time the only file that could be in use which would cause a failed update is firefox.exe and getting info to help a user figure out which user is using firefox.exe (e.g. the most common scenario) can require additional privileges that might not be granted depending upon the user's account.