[Marketing-Public]Mozilla Design Problems
marketing-public at mozilla.org
Sun, 19 Oct 2003 21:12:11 -0500
Irwin Greenwald wrote:
>You have one error in your analysis. pref.bak is written when Mozilla
>is started, not when it closes; pref.js is written when it closes (check
>the time stamps on the two files). As a result, if prefs.js gets
>corrupted (which the user can only ascertain upon next startup),
>prefs.bak will also be corrupted.
>Be that as it may, we are in agreement that Moz and TB backup/recovery
>need to be addressed. Question is how do we get the developers on board?
I opened Microsoft Windows Explorer and navigated to my Mozilla 1.5
profile and left it open while I tested prefs.js. It seems that opening
and closing Mozilla on a web page has no effect on saving prefs.js.
Opening and changing a preference setting saves the setting the moment
the "OK" button is pressed. If I wait 2 minutes and then close Mozilla,
prefs.js is saved again with a new time stamp, and prefs.bak is saved
with the time stamp of the previous prefs.js file.
It appears to me that the backup of prefs.js is occurring correctly in
Mozilla 1.5. the question now is how do we get the developers to devise
a method of recalling prefs.bak and renaming it pref.js.
How do we get the developers on board?
That is the $64,000.00 question. :-\
>On 10/19/2003 3:07 PM, Michael Gordon wrote:
>>Irwin Greenwald wrote:
>>>Now that Mozilla, TB, and FB are to be offered as user programs, I
>>>believe it is time to address some design issues that affect recovery.
>>>First, a word as to my background to establish my credentials for
>>>bringing up these issues. I entered the programming profession in 1950,
>>>first as a scientific programmer and then as a system programmer, being
>>>concerned with utilities, compilers, and developing operating systems.
>>>The last five years of my career were spent demonstrating that we could
>>>break the security of most any computing system of the era (I retired in
>>>II. The nature of the problem
>>>As I began to understand Mozilla, I realized that there were two obvious
>>>problems with the design and one that is not so apparent:
>>>1. registry.dat is subject to corruption during crashes.
>>>2. prefs.js is subject to corruption during crashes,
>>>3. profiles are subject to corruption over long term use with multiple
>>>installs of nightlies and heavy account editing activity, which is
>>>typical of what testers do.
>>>#1 results in "profiles being lost", which we see too much of in our
>>>newsgroups. This is relatively easy to fix by knowledgeable users, but
>>>#2 results in "mail being lost" and/or "profiles being lost" . This
>>>usually means that a new profile is needed.
>>>#3 results in strange things happening with no explanation.
>>>III. Some suggested design changes
>>>1. Registry.dat should be closed as soon as profile selection is
>>>complete. Currently, it appears that registry.dat is kept open at all
>>>times, producing strange results on mozilla or OS failures. I realize
>>>that this would make "switch profile" impossible or slow, but who really
>>>2. Prefs.js should be split into two files, one for static account settings
>>>and one for "transient" data such as windows positions, sizes, etc. I
>>>don't care too much about the safety of the second. The first should be
>>>closed after startup and reopened only when account settings are
>>>edited. It should be backed up to date named files, and a "restore"
>>>command provided. Same for bookmarks (Moz and FB). Alternatively, the
>>>whole profile could be backed up to date-named directories, with
>>>provision for recovery.
>>>3. The long term decay of profiles possibly can be addressed by better
>>>cleanup, (e.g, deleting files when accounts are deleted, which has been
>>>a longstanding bug)
>>>IV. My Own Experience
>>>1. I don't recall ever losing registry.dat, but I see it often enough
>>>in user problems to be concerned. I believe the fix should be fairly easy.
>>>2. I have lost prefs.js a number of times, although not too often
>>>recently. OTOH, I haven't had a program or system crash in ages.
>>>3. I have experienced profile decay very recently. It is the
>>>explanation for my inability to write to newsgroups on some servers. I
>>>rebuilt my profiles for both Mozilla and TBird to overcome this
>>>problem. It is a very tedious task even when you know what you're
>>>doing. It would help if the software named the mail & newsgroup folders
>>>with the *account name* rather than the server name with an appended
>>>number. (I have manually changed these names myself so I can keep track)
>>>I believe some design changes are mandatory if we expect to "sell"
>>>Mozilla to end users. I have suggested some "cures" for problems I have
>>>encountered, either directly, or by helping other people. Your reaction
>>>to these ideas is solicited, and - if you agree that something needs to
>>>be done , your suggestions on how to make it happen would be appreciated.
>>>marketing-public mailing list
>>I agree with the problems you have encountered personally and the users
>>on the newsgroups. I have been a long time user of Mozilla family
>>products, and I have encountered some of these problems.
>>1. The registry.dat file had a problem with file size growth, the short
>>term fix for this was to open Mozilla (Netscape), delete the
>>registry.dat file, close Mozilla (this recreates registry.dat), and then
>>with the operating system tools navigate to registry.dat and change its
>>attribute to Read Only. If during the creation of the first Profile the
>>registry.dat is created and saved as a Read Only file this would prevent
>>further problems with corruption. If during the creation of a second
>>profile registry.dat is modified to a Read/Write file, the profile
>>created, and at the moment the file is saved it is changes back to Read
>>Only this should protect the registry.dat file from further changes.
>>Allowing only Profile Manager to write to registry.dat should solve a
>>whole lot of problems. One more suggestion on the registry.dat file,
>>when Profile Manager is opened to create a new profile, Profile Manager
>>should make a backup copy of registry.dat by date.
>>2. Prefs.js currently has a backup file in the users profile directory
>>called "prefs.bak". the backup copy is written to after each successful
>>closing of Mozilla. Perhaps what we need in the program group for
>>Mozilla is a Recovery application that allows the user to recover from
>>the last successful opening and closing of Mozilla. I think the backup
>>copy should be saved to a backup directory by date, each closing of
>>Mozilla should write a new file, and after x number of days the files
>>should be purged automatically. If Prefs.js were split into two
>>sections as you suggest then the user configuration with "user.js"
>>become obsolete. We then have to instruct the users on how to make
>>changes with "About:config". Currently there are several Mozilla
>>(Netscape) support pages that address how to create the user.js file and
>>a lots of examples of the changes that can be made in user.js. All of
>>into the user.js file.
>>3. When I installed Mozilla 1.5 I remember Profile Manager presenting me
>>with the options to remove my old Netscape Profile Name or Profile name
>>and files. This should solve the problem of profile decay. For beta
>>testers perhaps the best solution is to delete the old profiles and
>>create a new profile whenever a new version is released for testing.
>>The point version updates should not need a new profile.
>>Just my 3 cents worth, when I turned 60 my price went up :-P
>marketing-public mailing list
Character is doing the right thing...
Even when no one is watching...
A Proud User of Mozilla 1.5
Get your free copy here: