Some directories not read or executable, makes Mailnews disappear, and themes break.

VERIFIED FIXED in M17

Status

()

Core
XUL
P2
major
VERIFIED FIXED
18 years ago
10 years ago

People

(Reporter: Christos Cheretakis, Assigned: Syd Logan)

Tracking

({relnote})

Trunk
x86
Linux
relnote
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2-][nsbeta3+])

Attachments

(2 attachments)

(Reporter)

Description

18 years ago
Can start however using -mail command-line switch.
Currently on linux/2000061908

Comment 1

18 years ago
Working here on the same build.

Comment 2

18 years ago
I see "Mozilla Mail" on the Tasks menu with 2000061920.  marking wfm
Status: UNCONFIRMED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 3

18 years ago
Still don't get one. Removed .mozilla after installing 061902, but does not work.

Comment 4

18 years ago
I've talked to two other people who verified that this item is, in fact, on the 
tasks menu.  Please ensure that if you're running installer, you're actually 
installing the mail component.  verifying wfm for now...
Status: RESOLVED → VERIFIED
(Reporter)

Comment 5

18 years ago
still missing, 061920

Comment 6

18 years ago
xalkina@otenet.gr (Christos Cheretakis) you probably still have something
hanging around from a previous build.  make sure tha you've removed all mozilla
files.
(Reporter)

Comment 7

18 years ago
I always do :-)
(Reporter)

Comment 8

18 years ago
Still not there in 062408. I always remove all files from my mozilla
installation and the .mozilla directory. That's not it!

Comment 9

18 years ago
Reassigning to mail to let them figure this out :)
Status: VERIFIED → UNCONFIRMED
Component: Browser-General → Mail Window Front End
Product: Browser → MailNews
Resolution: WORKSFORME → ---

Comment 10

18 years ago
reassign
Assignee: asa → putterman
QA Contact: doronr → lchiang

Comment 11

18 years ago
Not sure how much more we can add to this :-)

Can you try to install to another directory?
QA Contact: lchiang → nbaca
(Reporter)

Comment 12

18 years ago
Will give it a try with next nightly, though don't think there's anything to
change. Iremove everything from /opt/mozilla where i install mozilla and my
personal .mozilla directory. If that's not enough, nothing will do it!
did you kill your profile (/users50) ?
(Reporter)

Comment 14

18 years ago
there's no such thing as /users50 in unix. btw, couldn't get latest build to
even unzip. will check with next one.
(Reporter)

Comment 15

18 years ago
Installed in /opt/mozo5.0 instead of /opt/mozilla, removed .mozilla directory,
but mozilla just does not want to let me read mail! It's still missing from the
menu!
(Reporter)

Comment 16

18 years ago
Installed in /opt/mozo5.0, instead of /opt/mozilla.
Removed .mozilla from my home directory.
Mail does not appear in Tasks menu of mozilla.
linux/062709

Comment 17

18 years ago
This is a complete mystery to me.  alec, putterman - do you know of any case 
when mail *wouldn't* be in the tasks menu?  The only possible cause I can think 
of is that if mail isn't installed (?)

Comment 18

18 years ago
is it on the task bar at the bottom of the screen?

Comment 19

18 years ago
What are all the menu items you do have in your Tasks menu?

Comment 20

18 years ago
add to qawanted to help reproduce this.  No one has had any luck reproducing 
this so far, including folks on mozilla.org QA.
Keywords: qawanted

Comment 21

18 years ago
Also, is it missing from every tasks menu in the app (composer, messenger, 
etc.) ?

Comment 22

18 years ago
Is mailTasksOverlay.xul in 
dist/bin/chrome/packages/messenger/messenger/content/?
(Reporter)

Comment 23

18 years ago
Bottom task bar, I assume, are the three icons on the left side, below the
status bar. First one starts navigator, second starts composer, third produces a
Javascript error, from the icon it seems it is Mail. JS error says line 0:
toAddressBook is not defined
(Reporter)

Comment 24

18 years ago
These are the items in my Tasks menu:
Navigator
Composer
<sep>
Address Book
Newsgroups (disabled)
<sep>
Privacy and Security (with submenus)
Tools (with submenus)
<sep>
<all open windows>
(Reporter)

Comment 25

18 years ago
Mail does not appear in any Tasks menu, not even its own!
(Reporter)

Comment 26

18 years ago
Finally, the file mailTasksOverlay.xul is in dist/chrome, not in
dist/bin/chrome.
Huh...

Comment 27

18 years ago
try moving mailTasksOverlay.xul to the directory that I mentioned and see what
happens.
(Reporter)

Comment 28

18 years ago
There's no dist/bin directory. Sorry!

Comment 29

18 years ago
as long as it's in the messenger directory with the other messenger files it 
should be fine.

Comment 30

18 years ago
I had someone checking this out on Linux, latest CVS. Marking WfM.
Go ahead if you wanna sort this out, Christos. 

Reopen if someone can confirm this happening on Linux again or if its not gonna 
work for you at all, Christos.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → WORKSFORME

Comment 31

18 years ago
reopening.  

waterson may have some steps:

Just installed the commercial build on Linux. I installed it as root,
ran it once so that component.reg would get built. Now I try to run as
user. No mail overlays loaded! (No little mail folder at the bottom, no
mail in task menu.)

Run as root. Mail is there.
Run debug mozilla build, mail is there.
Change all file permissions to ugo+w in /usr/local/netscape6. Still no
mail running as user.
Recreate profile. Still no mail.

Also, I got email from someone else jsabatke@execpc.com who ran into this.  I'll 
add him to the cc: list.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---

Comment 32

18 years ago
From alecf:

"I have had a few random occurances of this bug on my machine today - in once
instance I opened a mail search window, and mailWindowOverlay.xul wouldn't
load.. in the other instances, mozilla -mail wouldn't bring up any content..
but it almost always worked the second time.

This is on linux, never as root"

Updated

18 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 33

18 years ago
Because this is looking more common, I'm going to nominate this for nsbeta2.
I'm also going to reassign this to Alec.
Assignee: putterman → alecf
Keywords: qawanted → nsbeta2

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → M17

Comment 34

18 years ago
Putting on [nsbeta2-] radar.  Not critical to beta2.  Adding "relnote" keyword 
for PR2 release.
Keywords: relnote
Whiteboard: [nsbeta2-]
(Reporter)

Comment 35

18 years ago
Checked in
http://lxr.mozilla.org/mozilla/source/xpfe/communicator/resources/content/tasksOverlay.xul
to find Mail or something like that, but there does not seem to be anything.
Neither does in my tasksOverlay.xul file installed at mozilla's root in my box.
Nor does the tasksOverlay.dtd of en-US include the word Mail.
Don't know if that's any help...

Comment 36

18 years ago
we use dynamic overlays to make mail insert itself into the tasks menu - we do 
not exist in the global overlay file.

Comment 37

18 years ago
Repro on every build in the last three or so weeks on linux.

I delete *everything* before installing new build (as root, via cron):

#!/bin/bash
cd /usr/local/src
/bin/rm mozilla-*
/bin/rm -rf package/
/bin/rm -rf /home/leary/.mozilla
/usr/bin/ncftpget -u anonymous -p leary@nwlink.com ftp.mozilla.org .
/pub/mozilla/nightly/latest/mozilla-i686-pc-linux-gnu-talkback.tar.gz 
/bin/tar xvfz mozilla-i686-pc-linux-gnu-talkback.tar.gz 

Comment 38

18 years ago
Does not repro for root, *however*....

[root@jean leary]# diff -r .mozilla/ ~root/.mozilla/
Only in .mozilla/: default
Only in /root/.mozilla/: mozProfile
Binary files .mozilla/registry and /root/.mozilla/registry differ
[root@jean leary]#

why the difference?

Comment 39

18 years ago
arg, very sorry to flood :-(

does not repro for user after:

#chown -R leary package

*without* deleting .mozilla in my home dir.  So, it's a permissions thing with
the package/ tree...

Comment 40

18 years ago
syd figured out what the problem is...it's danm & hyatt's fault...
(Assignee)

Comment 41

18 years ago
problem is this:

if you start as user a, overlayinfo directories containing overlays.rdf file are 
created underneath chrome with permissions drwx------. If you run as user b, 
then you can't read or traverse these directories because of the permissions. I 
think they should be created drwxr-xr-w.

Comment 42

18 years ago
so who should get this?
Keywords: nsbeta3
(Assignee)

Comment 43

18 years ago
According to waterson, danm and hyatt should get this. But if they would like to
clue me in on what/how these dirs get created and where, I'd gladly do the work
and test it.

Comment 44

18 years ago
setting to browser, XPToolkit: XUL, reassigning.
Assignee: alecf → trudelle
Status: ASSIGNED → NEW
Component: Mail Window Front End → XP Toolkit/Widgets: XUL
Product: MailNews → Browser
QA Contact: nbaca → jrgm

Comment 45

18 years ago
->danm
Assignee: trudelle → danm
(Assignee)

Comment 46

18 years ago
Flush() is always creating files with permissions 0700. This is wrong for the 
case of stuff created below chrome, in which case 0755 is more appropriate. A 
solution that seems to have some agreement would be to add an argument to 
Flush() that tells Flush() what sort of permissions flags to use. We could make 
the argument be the Unix permissions flags (which will map to DOS/Windoze bits) 
or we can pass in some enumeration value(s) OR'd together. If you want, hand me 
this bug and I will be glad to come up with a workable solution.
(Assignee)

Updated

18 years ago
Severity: normal → major
Priority: P3 → P2

Comment 47

18 years ago
SOLUTION: I did an strace on this and found that it is opening
chrome/installed-chrome.txt for write.  When I chmodded it o+w it started to
work again.  I don't see why it should be writing this file in
particular and I don't want any user process writing in my install
tree at all, thankyou.
(Assignee)

Comment 48

18 years ago
Doug: see earlier comments. We are a component based piece of software. During 
component registry, we have to write certain things into chrome. It is normal. 
The solution is to get the permissions correct.

Comment 49

18 years ago
During the strace I saw that it tried to write on the component registry,
 got denied permission, and then opened another copy in the user's file
space. Why doesn't it do the same thing with chrome? That seems like
the proper approach to me.  By the way, I love Mozilla mail - it's the
best client going for me, and I use it all the time despite the
various problems and crashes.  Thanks!

Comment 50

18 years ago
This bug, I think, is miscategorized/mis-summarized. The fact that mail 
is missing from the Tasks menu is only a symptom of the fact that mail is just 
plain missing altogether when logging in as anything other than root! Mail is 
nowhere to be found in Preferences, the Tasks Menu, or the Component Bar. Is 
this a XUL problem, or something else entirely?

Comment 51

18 years ago
I think that the real problem is that nsIFile (or some such) is creating files 
using the wrong permission bits, and not letting umask filter them. This causes 
the installation (when run as root) to create a directory with 0600 permissions 
(or some such). I'm pretty sure this is a dup of another bug -- or vice versa.

dougt, sound familiar? 
(Assignee)

Comment 52

18 years ago
dougt claims to have fixed. Assigning to him so he can add comments and close.
Assignee: danm → dougt

Comment 53

18 years ago
last week, I changed the default permission of the xpcom file io streams to 0666 
(man 2 umask).  I am not sure if this made any difference.  

Comment 54

18 years ago
this worksforme with todays build.  
Status: NEW → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → WORKSFORME

Comment 55

18 years ago
This still happens on build 2000.07.30.05, after a virgin install using the
installer, all distribution and user directories deleted.  The problem went away
after I did a chmod a+rx on /usr/local/mozilla/chrome/overlayinfo and all its
subdirectories and files.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Comment 56

18 years ago
*** Bug 46984 has been marked as a duplicate of this bug. ***

Updated

18 years ago
Keywords: relnote2

Comment 57

18 years ago
On linux build 2000073009 M18 nightly, the overlayinfo directory is still being
created mode 700.  It should probably be mode 755 so that other users can enter
the directory.

drwx------    6 root    root        1024 Jul 30 15:28 overlayinfo

Clearing nsbeta2- status for reevaluation by PDT.  This is a simple fix and
should probably be done before m17 is released.
Whiteboard: [nsbeta2-]

Comment 58

18 years ago
Adding dependency meta bug, updating summary.
Blocks: 41057
Summary: Mail missing from Tasks menu → Some directories not read or executable, makes Mailnews disappear.

Updated

18 years ago
No longer blocks: 41057

Updated

18 years ago
Blocks: 41057

Comment 59

18 years ago
Syd, mozilla-bin must not write to the inst dir. This is a severe security
problem. See bug 41037 and bug 42184.

Comment 60

18 years ago
I think Ben meant bug 41057 not bug 41037.
(Assignee)

Comment 61

18 years ago
Ben, but it does. So, are you going to change that? In the meantime, a quick fix
will avoid users in the scenario from talking about from losing access to mail
news until some other architecture is devised.

So, let's make the current design work, and stop fussing about how it might be
better, ok?

Comment 62

18 years ago
Putting on [nsbeta2-] radar.  Not critical to beta2.  Adding "relnote" keyword 
for PR2 release. Release note that user might have to chmod for the 
directory...is that a workaround for this problem?
Whiteboard: [nsbeta2-]

Comment 63

18 years ago
plussing, sounds nasty.
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3+]

Comment 64

18 years ago
*** Bug 44338 has been marked as a duplicate of this bug. ***

Comment 65

18 years ago
Bug 44338 is about the classic theme not appearing in prefs, but the cause was
determined to be the same as this bug, that overlayinfo is not readable by other
users.  So, not only does this bug break mail/news but also themes. :(
Summary: Some directories not read or executable, makes Mailnews disappear. → Some directories not read or executable, makes Mailnews disappear, and themes break.

Comment 66

18 years ago
Does anyone know or have tracked down what code creates these directories?  What 
permissions are they 0666?

(Assignee)

Comment 67

18 years ago
I did, a while back. Read earlier. It is the component registry, and the flush 
call in rdf needs a perms flag (in this case) to cause the underlying fs code to 
use 766 (the rest of the flush calls can just pass some predefined value so they 
use the value they always used before so we don't break anything). I've 
discussed with rjc and hyatt, both like it, let's do it.

Comment 68

18 years ago
Flush() creates directories??  something is wrong.

Comment 69

18 years ago
okay.  found the problem.  all nsFileStreams (nsFileSpec io) use 0666 as the 
permission.  It was once 0700 but I change it to 0600 based on man 2 umask.  I 
guess we need to do something else, like 0755 as I initally though that we 
should do.  

Comment 70

18 years ago
Created attachment 12276 [details] [diff] [review]
permission change from 0666 --> 0755

Updated

18 years ago
Blocks: 44338

Updated

18 years ago
No longer blocks: 44338
Here's a diff to get the RDF XML datasource to use 755 instead of whatever 
default nsIFile uses:

Index: mozilla/rdf/base/src/nsRDFXMLDataSource.cpp
===================================================================
RCS file: /cvsroot/mozilla/rdf/base/src/nsRDFXMLDataSource.cpp,v
retrieving revision 1.96
diff -r1.96 nsRDFXMLDataSource.cpp
822c822
<     nsOutputFileStream out(path);
---
>     nsOutputFileStream out(path, nsOutputFileStream::kDefaultMode, 00755);
Assignee: dougt → syd
Status: REOPENED → NEW

Comment 72

18 years ago
actually, this is nsFileStreams, which is nsFileSpec
dougt: You are right, I meant nsFileSpec... which RDF is still using for writing 
out RDF/XML files.  Anyway, the diff is still correct for the issue at hand.  :^)
(Assignee)

Comment 74

18 years ago
Fixed
Status: NEW → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 75

18 years ago
This is *not* fixed in Linux build 2000080505.

Starting Mozilla as root, I can see mailnews, and I can download themes from
x.themes.org.

Starting as a normal user I do not see mailnews, nor do downloaded themes appear
in prefs.
(Assignee)

Comment 76

18 years ago
When you say you can't see mailnews, does that mean there is a tasks menu item 
but that it doesn't work? Or there is no tasks menu item? Can you recursively ls 
-l dist/bin/chrome/overlayinfo and attach to this bug report? Also, what is your 
umask set to when you installed, or when you first ran?
Doug, am I reading the patch right?  You made the default permissions be 0755 
for all files, including directories?  That's not right, if so: calling context 
is required to know whether to use 0666 (modified by umask, as usual) for a 
regular file, or 0777 (modified by umask again) for a directory.  Some Unix 
utilities use 0755 for the default mode when creating necessary directories 
along the path to a new file, btw, but I think umask should govern which bits 
are turned off, so 0777 seems best in general.

Is the problemt that the "accessMode" is used both for creating the ultimate 
(leaf) file, and for creating any necessary directories along the path?  Or are 
we really creating leaf directories as well as files using the same method(s), 
in which case we've overloaded badly?

/be

Comment 78

18 years ago
Created attachment 12452 [details]
Permissions for /usr/local/mozilla/chrome/overlayinfo etc

Comment 79

18 years ago
Linux build 2000.08.06, umask is 002.  Installed with installer, complete
install.

Comment 80

18 years ago
no.  we did not use that patch.  

the final fix was in RDF (like other places in the code) to create files with 
755 permission. 

The problem is that nsFileSpec creates directories with 0700:

const mode_t mode = 0700;
nsFileSpecHelpers::MakeAllDirectories((const char*)ioPath, mode);


nsLocalFile (nsIFile) fixes this problem.  From the comment:

Ancestor directories get the same permissions as the file we're creating, with 
the X bit set for each of (user,group,other) with an R bit in the original 
permissions.  If you want to do anything fancy like setgid or sticky bits, do it 
by hand.
Doug: righteous, but set my silly mind at ease: when you wrote that "RDF 
[creates] files with 755 permission", you mean directories only, not regular 
files that aren't truly executable?

/be

Comment 82

18 years ago
files only :-(  that is probably why people are still complaining that this does 
not work for them.


Syd, can you verify that changing the permissions in nsFileSpecUnix, does indeed 
fix this problem?
(Assignee)

Comment 83

18 years ago
Dougt: setting to 755 is not going to cause the failure, that is silly :-) -- 
just means the file is incorrectly marked as executable, not that it can't be 
read (if you try to execute the file the shell will try to interpret it and 
fail). The bug that some people still have for whatever reason is that a user 
that was not the creator of the overlayinfo dir is unable to read files because 
the directories about are not readable.

Brendan is prolly right, the 755 on files is unnecessary and perhaps a tad evil, 
the rdf-created stuff can be 644, and we should change it. My bad. The 
directories in the path should be 755 so they can be accessed by a different 
user than the 
creator, that is what the change in nsFileSpecUnix did, as dougt described 
earlier (700 was too restrictive), and what this bug is all about. Regardless of 
the issue with the "file" perms, my checkins fixed the bug as it was originally 
described. I verified it with the default umask and with a umask of 002. 

As you can see in the last attachment (by zach), the overlayinfo dir has been 
created with permissions inconsistent with the checked in fix. Setting umask to 
002, I did not get the same result as Richard Zach -- my permissions on 
overlayinfo are what I would have expected, drwxr-xr-x (his are drwx------ which 
will cause the failure case). 

I am *not* using the installer, but debug builds from m18 tip. The installer 
does not create chrome/overlayinfo so I can't see it as being relevant. 
Syd: just to be sure we agree, the octal literal passed for regular file mode 
should be 0666, and let umask turn it into 0644 or 0664 as the user desires.  
For directories created implicitly along the path to a new file, we should do 
what shaver et al. did in nsLocalFileUnix: use the file's mode with an 'x' bit 
for every 'r' bit added.

IOW, please to be respecting my umask setting, dammit!

/be
(Assignee)

Comment 85

18 years ago
Undid the perms setting in rdfxmldatasource, picking up defaults for files which
are 0666 (I still think of we only want 644 it is strange to be setting 666 with
the hopes the umask will do what we want, why the heck not just use 644?)
Anyway, back to where we were except the real problem is solved, dir permissions
are correct.

Still need more info as to why someone is seeing 700 on overlayinfo, that should
no longer be happening... still works great for me:

[slogan@sydlap chrome]$ ls -l
total 5
lrwxrwxrwx   1 syd      users          51 Aug  7 16:20 all-locales.rdf ->
/opt/raptor/mozilla/dist/bin/chrome/all-locales.rdf
lrwxrwxrwx   1 syd      users          52 Aug  7 16:20 all-packages.rdf ->
/opt/raptor/mozilla/dist/bin/chrome/all-packages.rdf
lrwxrwxrwx   1 syd      users          49 Aug  7 16:20 all-skins.rdf ->
/opt/raptor/mozilla/dist/bin/chrome/all-skins.rdf
drwxr-xr-x   4 syd      users        1024 Aug  7 16:21 communicator
drwxr-xr-x   5 syd      users        1024 Aug  7 16:21 locales
drwxr-xr-x   6 syd      users        1024 Aug  7 16:20 overlayinfo
drwxr-xr-x   7 syd      users        1024 Aug  7 16:21 packages
drwxr-xr-x   4 syd      users        1024 Aug  7 16:20 skins
lrwxrwxrwx   1 syd      users          52 Aug  7 16:20 user-locales.rdf ->
/opt/raptor/mozilla/dist/bin/chrome/user-locales.rdf
lrwxrwxrwx   1 syd      users          50 Aug  7 16:20 user-skins.rdf ->
/opt/raptor/mozilla/dist/bin/chrome/user-skins.rdf
syd: if you know for sure that 0644 is right (no group member should be able to 
write, or to unlink the file from a sticky dir), go for it.  In a general 
purpose API, you can't know that.  Umask can only clear bits, never set them.  
Some people run in group-write-access mode, with umask of 002.  Others use 022. 
Different strokes, but don't preempt the choice.

/be
(Assignee)

Comment 87

18 years ago
Sure, let's leave it at 0666. 

Comment 88

18 years ago
The number of the beast (Mozilla) ;-)

Comment 89

18 years ago
It's back!  Mail no longer works unless you run it as root. This seems like more
of these "Can't write in the registry" problems again.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 90

18 years ago
Doug Collins, did you run mozilla once first as root to register the necessary
files?  You may be experiencing bug 42184.  If so then this bug is fixed or a
dup of bug 42184.  I don't have easy access to a linux box right now, can anyone
else on linux confirm this?

Comment 91

18 years ago
Yes, it's caused by the same thing as bug 42184 - basically because the registry

Comment 92

18 years ago
Doug, didn't get all of your last comment. Please update.

At any rate, if I either run the mozilla installer, or do a tar xvzf, and 
then run as root to get the initial registration done, when I subsequently
run as ~jrgm, I run fine, I have mail overlays, can run mail, can change
themes, ... the overlayinfo and other files created on the initial run as 
root are created with 644 for files and 755 for directories (given a root 
umask of 022).

Comment 93

18 years ago
marking as dup per Doug's last comment

*** This bug has been marked as a duplicate of 42184 ***
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → DUPLICATE

Comment 94

18 years ago
All my great comments got deleted for some reason. Anyway, the gist
of it is that bug 42184 sounds like it is being treated like an
esoteric security issue but what I'm seeing today is that Moz
won't even *BOOT* as a user anymore but it runs perfectly as root.
So I "chmod -R a+w ." and guess what? Now it works fine.

Comment 95

18 years ago
John, did you change the owner/permissions back after the install-run and before
the run as normal user?

David, Doug Collinge, if you ran Mozilla once as root (and it ran fine), then
change the owner, and it doesn't work and more, then this is not a dup of bug
42184. If anything, it's a bug of bug 41057.

Comment 96

18 years ago
No. To be clear, I did not use 'chmod' at any time. After the initial run 
as root, I could run as 'jrgm' without error. 

However, what Doug says is correct: if you do not do the initial run as 
root (just do the install/untar as root), and then try to run as 'user', 
the program aborts completely. [I don't know if that is new behaviour or
if it was already like that, since I don't typically install the daily 
builds as root on my system].

Comment 97

18 years ago
> I did not use 'chmod' at any time

I did not use 'chown' or 'chmod' at any time

Comment 98

18 years ago
Seems like I misunderstood you, John. What you describe is indeed bug 42184. But
Doug Collinge seem to be completely unable to run Mozilla as normal user, which
would be a dup of bug 41057. Anyway, doesn't really matter (unless you want to
come up with a workaround again). All of you know the relevant bugs now :).

Comment 99

18 years ago
I verified again today that Mozilla crashes when run as a user. Details
are posted against bug 42184 and bug 41057.  This bug may be a duplicate
but it sure isn't resolved.

Comment 100

18 years ago
Okay, the crux of _this_ bug was what syd said, Jul 13: overlayinfo was 
being written with zero rwx permissions for 'go'. That is fixed: if user
A does the install and initial run, then user B can run that installed app.

The other bugs cover different issues: what app should do the initial install,
and whether bob the user needs write access to the bin directory at runtime
(although I did not need write access and could run fine). 

Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

Comment 101

18 years ago
back to fixed.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 102

18 years ago
verified.
Status: RESOLVED → VERIFIED
(Assignee)

Updated

16 years ago
Blocks: 116669

Updated

10 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.