Spotted in TB 1.5b2 but there's no Software Update component in Thunderbird on bugzilla. Thunderbird installed by Administrator into "C:\Program Files\Mozilla\Thunderbird 1.5b2" Never run as Admin, don't know if that matters. When running TB as normal user the following appears (after a raft of other RDF related issues) in the JavaScript console. Error: [Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIFile.create]" nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)" location: "JS frame :: file:///C:/Program%20Files/Mozilla/Thunderbird%201.5b2/components/nsUpdateService.js :: getUpdatesDir :: line 294" data: no] Source File: file:///C:/Program%20Files/Mozilla/Thunderbird%201.5b2/components/nsUpdateService.js Line: 294 This appears to be the code http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/update/src/nsUpdateService.js.in#294 From what I can gather there, it's barfing because the update dir doesn't exist. It can't be created either since the user is non-priv'd, and updates couldn't be done anyway, since the non-priv couldn't overwrite the install.

This also occurs when installing spelling dictionaries. Nice that the dialog pops up to say Installation was successfull. The log says otherwise, sort of. Only to contradict itself and agree with the dialog. Should dictionaries be considered profile installations? I'd call this a bit serious for TB in any environment that has non-priv'd users. ------------------------------------------------------------------------------- file:///[snip]/spell-en-GB.xpi -- 2005-10-21 10:36:43 ------------------------------------------------------------------------------- spell-en-GB (version 0.1) ----------- ** ERROR (-202): Installing: C:\Program Files\Mozilla\Thunderbird 1.5b2\components\myspell\en-GB.dic ** ERROR (-202): Installing: C:\Program Files\Mozilla\Thunderbird 1.5b2\components\myspell\en-GB.aff ** ERROR (-202): Installing: C:\Program Files\Mozilla\Thunderbird 1.5b2\components\myspell\README-en-GB.txt Install completed successfully -- 2005-10-21 10:36:45 ------------------------------------------------------------------------------- file:///C:/[snip]/spell-af-ZA.xpi -- 2005-10-21 10:36:52 ------------------------------------------------------------------------------- spell-af-ZA (version 0.1) ----------- ** ERROR (-202): Installing: C:\Program Files\Mozilla\Thunderbird 1.5b2\components\myspell\af-ZA.dic ** ERROR (-202): Installing: C:\Program Files\Mozilla\Thunderbird 1.5b2\components\myspell\af-ZA.aff ** ERROR (-202): Installing: C:\Program Files\Mozilla\Thunderbird 1.5b2\components\myspell\README-af-ZA.txt Install completed successfully -- 2005-10-21 10:36:53

slipped onto the radio button on last commit

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051020 Firefox/1.5 ID:2005102021 Updating as an admin works in any case. Just downloaded and tried this build: http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2005-10-19-08-mozilla1.8/

The issue clearly isn't if updating works [or not] as a priviledged user, it's that when running as a non-priviledged user it: i. barfs an unhandled exception on startup when it can't find the update directory ii. lies about installing updates (dictionaries) which i suspect it's trying to install into the wrong place anyway. Re (i): If the user cannot anyway perform a system-wide update, don't try and certainly don't try an exception that isn't handled. Or rather handle the exception. Re (ii): Do I _really_ need the someone with Admin rights (who may be at the other end of the word) to install a dictionary for _my_ use? I can install a normal extension into my profile, are dictionaries somehow special?

I see an error as well (after clicking the Check for Updates button): Error: [Exception... "'Failure' when calling method: [nsIWritablePropertyBag::getProperty]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://mozapps/content/update/updates.js :: anonymous :: line 614" data: no] Source File: chrome://mozapps/content/update/updates.js Line: 614 But the update is successfull.

I see the same error appear in Firefox when trying this build: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2005-10-19-06-mozilla1.8/

It is important that Firefox/Thunderbird is not run by Admin at the end of the installer, since the updates directory is created on that first launch. Bug 309183 handles a similar case, adding Ben Turner to CC The dictionaries problem should be spun off to a different bug in the Thunderbird product, since that is separate code.

They almost got it with #309183, but maybe it's not failing correctly if the directory doesn't exist, rather than is not writable. bug 309183 comment 10 seems to have tried to head this off at the pass but maybe tripped off the edge first. The dictionary thing appears to be similar to bug 272440 where it's almost summarily dismissed :) That's pointing at Linux/Suite though so it's probably a more general problem. Bug 216382 is exactly right, dictionaries are installed in the wrong location. Shoulda checked first. Sorry

For comments #5 and #6 I filed Bug 313258.

Resolved bug 313258. Thanks, Ria! I'll take a look at this case later on this afternoon. But yeah, it looks like we might have missed something in bug 309183. Nominating for rc1.

I'm sure my voice counts for nought :) but if TB (and others likewise affected) is to be considered an option in places where user != admin [and that is a growing group, not just banking anymore] then I hope it's cleared up before the much vaunted next-release.

Paul, can you give me some details on your limited permissions? And which directories do/don't exist? You should have an 'updates' directory and a '0' directory within that one.

C:\Program Files\Mozilla\Thunderbird 1.5b2>dir /a:d Volume in drive C has no label. Volume Serial Number is B4B0-6148 Directory of C:\Program Files\Mozilla\Thunderbird 1.5b2 2005/10/21 07:53 <DIR> . 2005/10/21 07:53 <DIR> .. 2005/10/21 07:53 <DIR> chrome 2005/10/21 07:53 <DIR> components 2005/10/21 07:53 <DIR> defaults 2005/10/21 07:53 <DIR> extensions 2005/10/21 07:52 <DIR> greprefs 2005/10/21 07:52 <DIR> plugins 2005/10/21 07:52 <DIR> res 2005/10/21 07:53 <DIR> uninstall 0 File(s) 0 bytes 10 Dir(s) 3,006,693,376 bytes free NTFS permissions for C:\Program Files\Mozilla\Thunderbird 1.5b2 via Properties -> Security -> Advanced -> Effective Permissions. Effective Permissions [X]=YES [ ]=NO: [ ] Full Control [X] Traverse Folder/Execute File [X] List Folder/Read Data [X] Read Attributes [X] Read Extended Attributes [ ] Create Files/Write Data [ ] Create Folders/Append Data [ ] Write Attributes [ ] Write Extended Attributes [ ] Delete Subfolders and Files [ ] Delete [X] Read Permissions [ ] Change Permissions [ ] Take Ownership Owner is LOCALHOST\Administrator My login is a User If I were a Power User I'd have enough permissions, but then so would any rat poo that WinXP let wander through the door :) Installed as LOCALHOST\Administrator this morning after download from www.mozilla.org link from homepage.

Thanks, Paul. I'd be willing to bet money that we're failing here: http://lxr.mozilla.org/mozilla/source/toolkit/mozapps/update/src/nsUpdateService .js.in#925 This should be easy to fix this afternoon. I can't do more now because I'm at work ;-) Perhaps on my lunch break?

I suspect it's a little more complicated than that :) There are a number of places in that file which do not check the return value of getUpdatesDir() before either using directly or handing off to something that also doesn't check != null. != null assumes a try/catch wrapper around the create at http://lxr.mozilla.org/mozilla/source/toolkit/mozapps/update/src/nsUpdateService.js.in#295 Use without checking http://lxr.mozilla.org/mozilla/source/toolkit/mozapps/update/src/nsUpdateService.js.in#333 http://lxr.mozilla.org/mozilla/source/toolkit/mozapps/update/src/nsUpdateService.js.in#589 Handing off http://lxr.mozilla.org/mozilla/source/toolkit/mozapps/update/src/nsUpdateService.js.in#988 ... to something that doesn't check http://lxr.mozilla.org/mozilla/source/toolkit/mozapps/update/src/nsUpdateService.js.in#323 Handing off http://lxr.mozilla.org/mozilla/source/toolkit/mozapps/update/src/nsUpdateService.js.in#925 ... to something that doesn't check http://lxr.mozilla.org/mozilla/source/toolkit/mozapps/update/src/nsUpdateService.js.in#306 I'd either check for validity at each point of use or, possibly simpler but less robust, create the 'updates/0' during installation. Creating the directory during installation would fallback to the already implemented (bug 309183) permissions failure mode. It doesn't handle removal of updates/0 post-installation, but that's another issue entirely.

This should fix us up. Give this patch a shot and make sure that it fixes your problem.

Nicely done. Just goes to show how little I know :) WORKSFORME now. Tested on TB 1.5b2 on WinXP SP2, initial config as described in previous comments.

Comment on attachment 200364 [details] [diff] [review] patch v1.0 Looks good to me. Thanks for the quick patch Ben!

Comment on attachment 200364 [details] [diff] [review] patch v1.0 This is a very low-risk fix.

fixed-on-trunk

fixed1.8

Less than 12h from report to fix commited. Fantastic!