1140833 - Cannot install add-ons, "Nightly cannot modify the needed file". Error "Failed to remove file ... extensions\trash\

Status: RESOLVED WORKSFORME

(Toolkit :: Add-ons Manager, defect)

Description

[Rapper_skull]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150307030233

Steps to reproduce:

I tried to install some add-ons from addons.mozilla.org. They were: Flagfox, Colorzilla and IE Tab 2.


Actual results:

I can't install Flagfox because it says "Flagfox could not be installed because Nightly cannot modify the needed file". The other two installed fine, and are listed in about:addons, but they say I have to reboot to install them. I rebooted many times, but nothing changes. I already tried to delete compatibility.ini, extensions.ini and extensions.json from the Nightly profile folder, but after the reboot all the extensions installed but these two.


Expected results:

The extensions should install without issues.

Comment 1

[Dave Townsend [:mossop]]

Please open about:config, find extensions.logging.enabled then restart. Now go to the install page, open the browser console (tools -> web developer -> browser console), clear it then try to install the extension. Copy any messages logged in the browser console into this bug.

Comment 2

[Rapper_skull]

I read the log and the problem was that Nightly couldn't delete an xpi file in extensions/trash. I deleted it manually and all three extensions installed fine. I don't know why Firefox have to delete all the files in the extensions trash before installing an add-on, but this behavior can sometimes cause some problems, like this one.

Here is the affected row of the log:
addons.xpi	ERROR	Failed to remove file C:\Users\PC-PC\AppData\Roaming\Mozilla\Firefox\Profiles\udxz6mfa.Default User\extensions\trash\[e-mail]: [Exception... "Component returned failure code: 0x80520015 (NS_ERROR_FILE_ACCESS_DENIED) [nsIFile.remove]"  nsresult: "0x80520015 (NS_ERROR_FILE_ACCESS_DENIED)"  location: "JS frame :: resource://gre/modules/addons/XPIProvider.jsm :: recursiveRemove :: line 1317"  data: no] Stack trace: recursiveRemove()@resource://gre/modules/addons/XPIProvider.jsm:1317 < forEach()@self-hosted:206 < recursiveRemove()@resource://gre/modules/addons/XPIProvider.jsm:1332 < DirInstallLocation_getTrashDir()@resource://gre/modules/addons/XPIProvider.jsm:7353 < DirInstallLocation_installAddon()@resource://gre/modules/addons/XPIProvider.jsm:7375 < AI_startInstall/<()@resource://gre/modules/addons/XPIProvider.jsm:5816 < next()@self-hosted:670 < TaskImpl_run()@resource://gre/modules/Task.jsm:330 < Handler.prototype.process()@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:867 < this.PromiseWalker.walkerLoop()@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:746 < this.PromiseWalker.scheduleWalkerLoop/<()@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:688 < <file:unknown> Log.jsm:749:0

Comment 3

[Wayne Mery (:wsmwk)]

Rapper, have you seen this since last comment in March?

Comment 4

[Rapper_skull]

I've not experienced this bug anymore after manually deleting the files and reinstalling the add-ons.

Comment 5

[Wayne Mery (:wsmwk)]

mossop, do you think there is still an underlying problem here?  

And, you agree with the following from bug 1037649 comment 3
"This is safe [the error], and in certain conditions is even expected due to file locks on Windows. The directory should be emptied the next time Firefox starts up. 

Context: The trash directory exists partly due to this type of problem, and partly so that we can do a rollback when something like an upgrade fails.

Comment 6

[Dave Townsend [:mossop]]

(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #5)
> mossop, do you think there is still an underlying problem here?  
> 
> And, you agree with the following from bug 1037649 comment 3
> "This is safe [the error], and in certain conditions is even expected due to
> file locks on Windows. The directory should be emptied the next time Firefox
> starts up. 
> 
> Context: The trash directory exists partly due to this type of problem, and
> partly so that we can do a rollback when something like an upgrade fails.

The vast majority of cases like this are due to AV tools and other things specific to a users machine. I don't think there is anything more we can do here unless we get steps to reproduce more generally.