248097 - install extension fails when profile is in samba shared directory "getItemProperty failing for lack of an item" and then on restart "nsExtensionManager::_finishOperations ... nsExtensionInstaller__cleanUpStagedXPI :: line 997"

Status: RESOLVED INCOMPLETE

(Toolkit :: Add-ons Manager, defect)

Description

[Jan Krcal]

User-Agent:       Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7) Gecko/20040615 Firefox/0.9
Build Identifier: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7) Gecko/20040615 Firefox/0.9

I can download and install a extension as usual, in the Extension manager
informs me that I have to restart Firefox to be able to use this extension, so I
close Firefox and start it again.
A dialog appears saying "Firefox is finishing installing extensions. This could
take a minute...". I waited several minutes but it didn't go on. When I close
this dialog and start Firefox again it does the same.
When I delete extensions folder in my profile, it works again, but my extension
isn't installed understandably...

Reproducible: Always
Steps to Reproduce:
1.Start Firefox Profile Manager
2.Create brand new profile located within a samba mount (I have rwx access to
this share)
3.Run Firefox in this profile and install any extension (it worked this way with
several extensions, i.e. SingleWindow)
4.Restart Firefox

Comment 1

[:Gavin Sharp [email: [e-mail]]]

The cause of this is almost definitely a bad extension, and not the samba share.
Which extension is causing this problem? You seem to indicate that other
extensions work fine in the same environment so that pretty much narrows it down
to that specific extension.

Comment 2

[Jan Krcal]

I really don't know which statement in my post seems to indicate that other
extensions work in that environment... in my English that bad?

Anyway, I can't say for sure that it is a problem of samba share, but it doesn't
seem to me as a problem of a bad extension because:
1. I haven't found any extension that worked in this environment (tried several
that usually work for me)
2. When I tested on the same machine some of these extensions (that didn't work
on samba) with profile in local directory, it worked. I used the same steps to
reproduce (see above) with the difference that I chose some local directory
instead of samba share in step 2.

On the other hand I tested it in one environment only (because I haven't got
several networks at home...) so I can't generalize. 
Could anyone else try this and report the results, please?

Comment 3

[Nickolay_Ponomarev]

Can you reproduce this with Firefox 1.0?
Do you have correct permissions for profile folder and its contents (you seem to).

Comment 4

[Ari Maniatis]

I can confirm this bug also occurs when my share point is within an OSX Server
AFP (Apple filing protocol - the Apple equivalent to SMB) share point. Moving
the profile to a local drive fixes the issue.

Comment 5

[Benjamin Smedberg]

Ben Goodger will be landing a rework of a lot of the extension management code
shortly. We need to reexamine this bug after that time.

Comment 6

[Daniel Clemente]

This still happens with today's build.
The "Extensions" window always shows "This item will be installed after you
restart Firefox".


When you install an extension, you get this output:

*** getItemProperty failing for lack of an item. This means getResourceForItem 
               failed to locate a resource for aItemID (item ID =
http://ftp.mozilla.org/pub/mozilla.org/extensions/mouse_gestures/mouse_gestures-1.0-fx+mz+tb.xpi,
property = disabled)
*** getItemProperty failing for lack of an item. This means getResourceForItem 
               failed to locate a resource for aItemID (item ID =
http://ftp.mozilla.org/pub/mozilla.org/extensions/mouse_gestures/mouse_gestures-1.0-fx+mz+tb.xpi,
property = internalName)
*** getItemProperty failing for lack of an item. This means getResourceForItem 
               failed to locate a resource for aItemID (item ID =
{FFA36170-80B1-4535-B0E3-A4569E497DD0}, property = internalName)


The next time you open Firefox:

$> *** loading the extensions datasource
*** nsExtensionManager::_finishOperations - failure, catching exception so
finalize window can close [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIFile.remove]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame ::
file:///tmp/firefox/components/nsExtensionManager.js ::
nsExtensionInstaller__cleanUpStagedXPI :: line 997"  data: no]


And when you uninstall it:

$> *** loading the extensions datasource
*** nsInstallLogReader::_parseLine - failed to remove file [Exception...
"Component returned failure code: 0x80004005 (NS_ERROR_FAILURE)
[nsIFile.remove]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS
frame :: file:///tmp/firefox/components/nsExtensionManager.js ::
nsExtensionUninstaller__removeFile :: line 1150"  data: no]
*** nsInstallLogReader::_parseLine - failed to remove file [Exception...
"Component returned failure code: 0x80004005 (NS_ERROR_FAILURE)
[nsIFile.remove]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS
frame :: file:///tmp/firefox/components/nsExtensionManager.js ::
nsExtensionUninstaller__removeFile :: line 1150"  data: no]
******* Failed to remove extension uninstall log, with exception = [Exception...
"Component returned failure code: 0x80004005 (NS_ERROR_FAILURE)
[nsIFile.remove]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS
frame :: file:///tmp/firefox/components/nsExtensionManager.js ::
nsExtensionUninstaller__removeFile :: line 1150"  data: no]


The problems seem to be when removing files. At components/nsExtensionManager.js
, line 997, and line 1150.

Comment 7

[Wayne Mery (:wsmwk)]

related to bug 251692, to which bug 259801 was duped?

Comment 9

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

This was sent to the amo editors mailing list two months ago:



I encountered the following problem when reviewing an add-on.

I had a previous version installed and upgraded to the version I was reviewing. After a restart, the addon manager claimed the addon is not yet installed and will be installed in the next restart… and so on.

Looking in the extensions.log file I figured that the problem is as follows:

- When firefox upgrades an addon it first backs up the old addon to another directory called <extension-id>-trash

- Some of the target filenames (including path and drive) during this backup are longer than 260 characters – which is the maximum Windows XP supports. The backup therefore fails

- Since the backup fails, the new version never gets installed and remains in the staged xpis directory.

The concern here is that any user with a long enough windows user name may encounter this problem when upgrading this addon. The addon will never get installed, and the addon manager will be in a constant annoying state.

Note, BTW, that if a user uninstalls the old version and installs the new one everything will be fine – it’s the addition of the “-trash” to the name during the upgrade process that causes the problems.

There’s not much the developers can do about it since the old version is already out.  The previous version did indeed introduce some longer filenames in the extension, but that can’t be changed now.

What’s our policy on this? It doesn’t feel right to deny the update because this isn’t really an add-on specific problem. I can ask the developer to shorten their filenames for the future but that won’t really help the current upgrade.

Also, how is the author expected to deal with users that experience this problem?

Comment 10

[Dave Townsend [:mossop]]

(In reply to comment #9)
> This was sent to the amo editors mailing list two months ago:

This seems to be a different issue?

Comment 11

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Put it into bug 544711.

Comment 12

[Blair McBride [:Unfocused] (UNAVAILABLE)]

This was originally filed long long before the Add-ons Manager was rewritten, and has had no activity since then (save comment 9, which is unrelated). If this happens with the new Add-ons Manager, please file a new bug with fresh information.