214981 - Localstore.rdf not always created if missing ==> UI Customizations don't get saved.

Status: RESOLVED FIXED

(Thunderbird :: Preferences, defect)

Description

[Rob Stow]

User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5b) Gecko/20030802 Mozilla Firebird/0.6.1
Build Identifier: Mozilla Thunderbird 0.1 (20030723)

If you do not have a localstore.rdf in your profile, Thunderbird sometimes fails
to create a new one when you exit.  As a consequence, UI customizations that the
user has made will be lost when he/she exits Thunderbird.   Examples include the
loss of column size and order in the message list pane and loss of
customizations done to the toolbars.

Reproducible: Sometimes

Steps to Reproduce:
1. Create a new TBird profile and start TBird with that profile.
   Alternatively, use an existing profile but delete localstore.rdf.
2. Do something to "customize" the UI, such as reordering the columns in the
message list pane or move some buttons from the mail toolbar onto the menubar.  
3. Close TBird.

Actual Results:  
TBird often/sometimes fails to create a new localstore.rdf on exit, and hence
the customizations are lost.

Expected Results:  
Create a new localstore.rdf and save the UI customizations.

If you are unable to get TBird to create a localstore.rdf without your
intervention, then you can manually create a zero-byte file with that name
before running TBird.   This kickstarts the process and TBird will subsequently
overwrite the now pre-existing localstore.rdf and save your UI customizations.

See 
  Thread: Message list window not saving settings
  Server: secnews.netscape.com 
  Group:  netscape.mozilla.thunderbird 
  1st Message: snews://secnews.netscape.com:563/bgi36u$[e-mail]
For the discussion before this bug was filed.  That thread has confirmations
from at least two other TBird users.  All confirmations seem to occur on the
various Windows platforms - no non-MicroSoft confirmations yet. 

Rating this bug as "Major" - not sure if losing the UI customizations on exit
qualifies as the kind of dataloss needed for a "Critical" rating.

Comment 1

[Ronald Killmer]

This bug is an empediment to new user satisfaction and ease of use.

My thinking is some code to check for existance of the localstore.rdf in the
profile *.slt could trigger making the file if existance is false.  

Comment 2

[Rob Stow]

Your comment in the newsgroup about "*.slt" actually led me to test with both
salted and unsalted profiles.  The salting makes no difference to either the
occurrences of this bug or to the workaround by creating the zero-byte
localstore.rdf.

Comment 3

[Leonidas Jones]

I have reproduced this problem.  Firebird and Mozilla both recreate
localstore.rdf if it is missing, but Thunderbird does not.

Comment 4

[Kevin Teuscher]

If there is no localstore.rdf file in your profile directory when Thunderbird is
started, did a file called "savelocalstore.rdf" get created in your case?  I ran
a debug build (win32) and the localstore.rdf file from defaults/profile/ got
copied to my profile.  One time when I ran a release version [Mozilla
Thunderbird 0.2a (20030820)], I got a file 'savelocalstore.rdf'.  I have not
been able to do it again.  In most cases, no file gets created. 

Comment 5

[Kevin Teuscher]

Just did some further investigation.

In the debug build, the localstore.rdf gets copied from
defaults/profile/US/localstore.rdf.  The US subdirectory does not exist in the
directory structure of the release build.  Creating the US subdirectory and
copying a localstore.rdf file to this directory does fix the problem of no
localstore.rdf file being added to the profile.  Not sure if thunderbird is
supposed to default back to the main profile directory if the specified locale
does not exist.
Off to research more

Comment 6

[Rob Stow]

In reply to comment #4:

I am the reporter - assuming your question was addressed to me, though not
necessarily exclusively to me.   If I delete my localstore.rdf in order to
recreate the conditions necessary to provoke this bug, the bug recurs and
I do *not* get a file called savelocalstore.rdf anywhere on my hard drive.

Comment 7

[Kevin Teuscher]

Ok,
So this is definitely a problem with the builds that Scott has been dropping for
win32.  For all of the other builds that I have looked at (linux, solaris) there
is a locale specific diretory (defaults/profile/US) that is present in the
download.  The only one that doesn't have it is the win32 build.

Scott: is there a reason for this that I'm missing?

There may be an underlying problem that needs to be addressed in the profile
code, but I'm am definitely not an expert (or even a novice) in that area.  The
problem with not copying localstore.rdf comes from the fact that the locale
specific directory (defaults/profile/US) doesn't exist (in scott's builds), but
in nsProfile::DefineLocaleDefaultsDir() (see
http://lxr.mozilla.org/mozilla/source/profile/src/nsProfile.cpp#2064) the
default for the location to copy default files gets set to this directory
without any check to see if the directory exists.

So the question is:  Is it the code's responsibility to check if this directory
exists before setting the value, or is it the responsibility of the install to
make sure that this directory exists?

Kevin

Comment 8

[Scott MacGregor]

your analysis is a great help. fix should be easy now.

Comment 9

[Scott MacGregor]

Jason Kersey was seeing this too.

Comment 10

[Scott MacGregor]

Attachment: the fix

Comment 11

[Scott MacGregor]

fixed