128113 - user's new profile is messed up if mozilla files are installed read-only

Status: VERIFIED FIXED

(Core Graveyard :: Profile: BackEnd, defect)

Description

[Patrick Smith]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:0.9.8) Gecko/20020226
BuildID:    0000000000

When a user first runs mozilla, with no existing .mozilla directory, if the
files in the mozilla installation are read-only, then the user gets a corrupt
profile.  Most of the files in the user's new .mozilla directory are read-only
and have size 0.

Reproducible: Always
Steps to Reproduce:
1. Untar the tar.gz file (I was using one I had compiled myself, from the 0.9.8
sources).
2. Make the resulting files read-only:  find mozilla -type f | xargs chmod a-w
3. rm -rf ~/.mozilla
4. Start mozilla
5. Exit from mozilla
6. Take a look in ~/.mozilla/defaults/*

Comment 1

[Patrick Smith]

Sorry, I forgot to mention... this causes various problems, such as settings not
being saved.  For example, if I close the sidebar, exit mozilla, and restart
mozilla, the sidebar still appears.  See also bug 109377.

Comment 2

[Kai Lahmann (is there, where MNG is)]

I would call this WONTFIX, coz it may be planned to have readonly profiles.

Comment 3

[Grace Bush]

files created by  mozilla (default profile if no 4.x exists) or any other
profile created by user are not read only
these files are made to be writeable so users prefs and settings can be saved.
marking wontfix

 please reopen if you disagree

Comment 4

[Grace Bush]

marking!

Comment 5

[K'Trina Medina]

Verified wontfix

Comment 6

[Patrick Smith]

I've just retested this with Mozilla 1.1, and the problem is still there.

Here's the output of listing my ~/.mozilla/default/* directory:

total 961
drwx------    2 pat      pat           304 Sep 18 12:03 Cache
-rw-r--r--    1 pat      pat        938005 Sep 18 12:03 XUL.mfasl
-rw-r--r--    1 pat      pat          5225 Sep 18 12:03 bookmarks.html
drwxr-xr-x    2 pat      pat           160 Sep 18 12:03 chrome
-rw-r--r--    1 pat      pat           567 Sep 18 12:03 history.dat
-r--r--r--    1 pat      pat          6122 Sep 18 12:03 localstore.rdf
-r--r--r--    1 pat      pat           287 Sep 18 12:03 mimeTypes.rdf
-r--r--r--    1 pat      pat          2169 Sep 18 12:03 panels.rdf
-rw-r--r--    1 pat      pat            57 Sep 18 12:03 prefs.bak
-rw-r--r--    1 pat      pat           355 Sep 18 12:03 prefs.js
-r--r--r--    1 pat      pat          2335 Sep 18 12:03 search.rdf

When I started Mozilla, closed the sidebar, closed Mozilla, and restarted
Mozilla, the sidebar still appeared.

Note: in reproducing this, after untarring the Mozilla tarball, it is critical
to make the resulting files read-only (step 2 in the procedure I gave) before
running Mozilla the first time.

When creating a user's profile, Mozilla should set the permissions on the
profile files appropriately.  Instead, it appears to copy the permissions from
the sample profile taken from the tarball.

Comment 7

[Todd Cohn]

Patrick, we don't want the files to be read-only.  You can't save changes to
files that are read-only (obviously).   Thus, this is WONTFIX.  Please do not
re-open.

Comment 8

[Patrick Smith]

Todd, I don't think you understand this bug report.  You say "we don't want the
files to be read-only".  The bug is that the files _are_ read-only.

I won't reopen this; it's just a minor thing.  But you might want to consider
reopening it.

Maybe I wasn't clear enough in my explanation.  Let me try one more time.

Installing Mozilla involves three basic steps:

1) Compile it and make a tarball.

2) Untar the tarball into some directory visible to everyone who will use
Mozilla.  Let's say we do this in /usr/mozilla.

3) When a user runs Mozilla for the first time, $HOME/.mozilla is created and
populated with various default files.

It is important that the files under $HOME/.mozilla be writable, so the user's
changes can be saved.  On the other hand, it is not necessary (as far as I
understand) for the files under /usr/mozilla to be writable.  In fact, an
administrator might want these files to be unwritable, in order to reduce the
likelihood of accidentally modifying these files.  Such an administrator might 
run 'chmod -R a-w /usr/mozilla' after extracting the contents of the tarball.

Here's the bug:

*If* the files under /usr/mozilla are read-only, then some of the files placed
in $HOME/.mozilla the first time Mozilla is run are created read-only.


Here's the way it should be:

When Mozilla creates files under $HOME/.mozilla, those files should be writable,
even if the files under /usr/mozilla are not writable.

Comment 9

[Conrad Carlen (not reading bugmail)]

> Patrick, we don't want the files to be read-only.

Reading Patrick's comment, that does not seem to be what he's asking for. If
files end up in a new profile without write perm, this is indeed a bug.

Patrick, code I checked in recently for bug 177321 does set the appropriate
permissions on new profile files after copying them from defaults to the new
profile. Can you test with a nightly from after bug 177321 was checked in?

This should either be verified as WFM or FIXED (files in a new profile are
writable) or reopened, but not WONTFIX.

Comment 10

[Todd Cohn]

*doh* Right you are.  Read a little too fast the first time.  

Comment 11

[Patrick Smith]

Conrad, I will test this -- but probably won't have time until next week.

Comment 12

[Patrick Smith]

I've built Mozilla from
http://ftp24moz.newaol.com/pub/mozilla/nightly/2002-11-28-08-trunk/mozilla-source.tar.gz,
and tested this bug.

It seems to have been fixed.

Thanks!

Comment 13

[K'Trina Medina]

Verified. Working now per reporter.