305620 - Firefox cannot update an extension installed manually that contains read-only files

Status: RESOLVED DUPLICATE of bug 321333

(Toolkit :: Add-ons Manager, defect)

Description

[Dave Townsend [:mossop]]

When an extension already exists as a text file pointer in the extensions
directory, trying to upgrade the same extension using an xpi file fails.

After restarting firefox, EM says extension "will be installed when Deer Park is
restarted". The new xpi still exists in staged-xpis. After deleting the file
pointer and restarting, the updated extension installs correctly.

Info in console:

Item Location path changed: C:\Documents and Settings\Dave\workspace\buildid
Item ID: {8620c15f-30dc-4dba-a131-7c5d20cf4a29} Location Key: app-profile,
attempting to upgrade item...

safeInstallOperation: failed to clean up item location after its contents were
properly backed up. Failed to clean up: C:\Documents and
Settings\Dave\workspace\buildid ... rolling back file moves and aborting
installation.

ExtensionManager:_finishOperations - failure, catching exception - lineno: 1819
- file: undefined - [Exception... "Component returned failure code: 0x80004005
(NS_ERROR_FAILURE) [nsILocalFile.remove]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame ::
file:///C:/PROGRA~1/DEERPA~2/components/nsExtensionManager.js ::
safeInstallOperation :: line 1819"  data: no]

Comment 1

[Dave Townsend [:mossop]]

Upgrading this to critical and dataloss. It seems that when trying to upgrade
firefox goes and recursively deletes all the files at the location pointed to by
the file.

As far as I'm concerned, firefox should not be wiping files from outside the
profile or app dir even if I have told it where the extension is. It doesnt
delete the files when you just uninstall the extension.

Comment 2

[Mike Schroepfer]

Rob - is there any way you can take a look and at least prevent this from
deleting the files pointed to by the file pointer?

Comment 3

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

I'm testing it as I write this and in my case it updated the extension when I
updated it using uupdate and by installing using DnD onto the EM. I need to
investigate further.

Dave - specifically, how did you upgrade the extension.

Comment 4

[Dave Townsend [:mossop]]

It was clicking to download the extension from a web page as I recall.

Comment 5

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

Dave, I am 100% unable to reproduce... in all cases the extension was properly
updated. I upgraded an extension that had a file with an entry specifying the
path to the extension by:
using extension update
DnD of an xpi onto the EM
DnD of an xpi onto the browser
Dropped file into the profile's extensions dir
From a web page

In all of these tests I first placed a dummy file in the actual extension's dir
located outside of the profile's extensions dir and in the case of the update I
modified the extension's install.rdf so it had a lower version number. In all
cases the dummy file was no longer there after install. In the case where I used
update the version number was updated. In all cases the extension worked afterwards.

I am currently on Win32 as you are and the contents of the pointer file I
created were c:\{34274bf4-1d97-a289-e984-17e546307e4f}\ which is adblock's GUID.
I bring this up because it is the only thing I can think of that might be
different. So far this is WFM and specific steps are needed to reproduce
including an url to the extension used.

Comment 6

[Dave Townsend [:mossop]]

Ok I've narrowed this down further and this was failing because a number of the
files inside the extensions dir were read only so firefox was unable to delete it.

Heres my question though, from the way you put it it sounds like the plan all
along in this situation is to upgrade the extension in place, that is delete all
the files at the place where the file pointer points to and extract the xpi
there. Is this correct because it doesnt sound right to me. I was expecting the
file pointer to be deleted and the extension installed normally in this
situation, leaving the old extensions files intact.

Comment 7

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

Currently file pointers inherit the same features as the install location as the
location they are installed. So, if the location is read only the extension will
not be updated and it can't be uninstalled etc. from the ui. If you install
using a registry location you would get this behavior. I personally would expect
that if I upgrade an item pointed to by a file pointer that the item pointed to
would be upgraded. Since the install process is manual for the item pointed to
by a file pointer it might make sense to disable uninstall, update, etc. and
make management of the item 100% manual but installing a new version of the item
in the same location as the file pointer IMO should then be disallowed if this
were the case and require manually removing the file pointer first since it
would be manually managed.

Comment 8

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

Forgot to answer... when the file pointer capability was added several months
ago, upgrades have always upgraded the item in the location specified by the
file pointer.

Comment 9

[Dave Townsend [:mossop]]

Ok, I can't say Im too keen on the idea of it but I guess if the file pointers
are only aimed at devs and any software should be using the registry install
location then this is not so much of an issue. I just might find wherever these
bits are documented and complain to someone to put a bit of a warning next to it.

So really now this is just an issue with firefox's handling of extensions with
read-only files. Presumably firefox will never create read only files itself so
this will only affect developer installed extensions so I guess this needn't be
blocking 1.8b4?

Comment 10

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

If this is going to block 1.8b4 the desired behavior needs to be flushed out.
With manually installed items using a file pointer there is no way to workaround
permissions issues since we don't manage the install (see bug 189905 for one
example). Personally, I think it should be sufficient to add to the docs that
when installing an item using a file pointer in a location that the extension
inherits the same features available for that location and requires the same
permissions along with that when installing the extension manually by extracting
it that the permissions must be set properly on the extracted files... simply
put but you get the idea. Another option would be to remove the ability to
uninstall, upgrade, etc. since we can't be guaranteed that we can even remove
the pointer file, etc. since we didn't create it with the app.

Comment 11

[Dave Townsend [:mossop]]

I think (certainly for the branch) that info in the docs is all thats necessary.
How tricky would it be though to at least have a sensible warning message in the
console that it couldn't remove a particular file? That would probably solve a
lot of headaches for people like me trying to figure out what's going on.

Comment 12

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

Fixing summary since the EM has workarounds for the extensions it installs.

Comment 13

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

Dave, I am quite sure that with the checkin for bug 321333 that this bug is fixed. I am resolving this as a duplicate of that bug and if you find this is not the case please re-open this bug.

Also note, there is bug 323546 to change the behavior so instead of upgrading the extension in the location outside of the extensions directory it would remove the file pointer and install it in the extensions directory on upgrade.

*** This bug has been marked as a duplicate of 321333 ***