[Marketing-Public]Mozilla Design Problems

Irwin Greenwald marketing-public at mozilla.org
Sun, 19 Oct 2003 16:35:06 -0700


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?

On 10/19/2003 3:07 PM, Michael Gordon wrote:

>Irwin Greenwald wrote:
>>I. Introduction
>>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
>>needn't occur.
>>#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)
>>V. Summary
>>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.
>>Irwin Greenwald
>>Mozilla Champion
>>marketing-public mailing list
>Hello Irwin,
>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
>these samples have the JavaScript snippet available to copy and paste
>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
>Michael Gordon