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

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.

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?

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

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.

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.

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.

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

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?

(In reply to comment #9) > This was sent to the amo editors mailing list two months ago: This seems to be a different issue?

Put it into bug 544711.

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.