Closed Bug 313240 Opened 19 years ago Closed 19 years ago

Update service fails via exception when run as non-privileged user


(Toolkit :: Application Update, defect)

1.8.0 Branch
Windows XP
Not set





(Reporter: ptomli.bugzilla, Unassigned)


(Keywords: fixed1.8)


(1 file)

Spotted in TB 1.5b2 but there's no Software Update component in Thunderbird on

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 ::
:: getUpdatesDir :: line 294"  data: no]
Source File:
Line: 294

This appears to be the code

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
     ** ERROR (-202): Installing: C:\Program Files\Mozilla\Thunderbird
     ** ERROR (-202): Installing: C:\Program Files\Mozilla\Thunderbird

     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
     ** ERROR (-202): Installing: C:\Program Files\Mozilla\Thunderbird
     ** ERROR (-202): Installing: C:\Program Files\Mozilla\Thunderbird

     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:
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.
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

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.
Flags: blocking1.8rc1?
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 link from homepage.
Thanks, Paul.

I'd be willing to bet money that we're failing here:

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

Use without checking

Handing off
... to something that doesn't check

Handing off
... to something that doesn't check

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.
Attached patch patch v1.0Splinter Review
This should fix us up. Give this patch a shot and make sure that it fixes your
Attachment #200364 - Flags: review?(darin)
Nicely done. Just goes to show how little I know :)
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!
Attachment #200364 - Flags: review?(darin) → review+
Comment on attachment 200364 [details] [diff] [review]
patch v1.0

This is a very low-risk fix.
Attachment #200364 - Flags: approval1.8rc1?
Closed: 19 years ago
Resolution: --- → FIXED
Attachment #200364 - Flags: approval1.8rc1? → approval1.8rc1+
Flags: blocking1.8rc1? → blocking1.8rc1+
Keywords: fixed1.8
Less than 12h from report to fix commited. Fantastic!
Flags: blocking1.8rc1+ → blocking1.8rc1?
Flags: blocking1.8rc1? → blocking1.8rc1+
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.