58014 - Make sure that certain Profile files exists all the time

Status: VERIFIED FIXED

(Core Graveyard :: Profile: BackEnd, defect, P3)

Description

[racham]

Filing this bug to cover all the cases, where user happpens to delete any of the
files used by other compoenents :

List of those files :

1. bookmarks.html
2. localstores.rdf
3. mimeTypes.rdf
4. panels.rdf      - covered i.e., doing the right thing already
5. search.rdf
6. default-messages.rdf

Today, we do drop all this files in the profile folders for both new and
migrated cases. Everything will work fine in a normal user case. If user,
accidentally deletes any of the uncovered files above, we are at a loss.
Conrad had put together a nice routine, EnsureProfileFileExists(), while
implementing DirectoryService for profile manager.

Comment 1

[racham]

(cont...) and that mechanism should be used to apply to makesure we copy a
default profile file into that profile fodler.

Comment 2

[Conrad Carlen (not reading bugmail)]

Easy enough. For default-messages.rdf, the JS code handles copying the file from
defaults itself. That is the problem here - having inconsistent rules for which
files are made (or copied from defaults) by directory service and which aren't.
I think comments in
<http://lxr.mozilla.org/seamonkey/source/modules/appfilelocprovider/public/nsAppDirectoryServiceDefs.h
> would help.  

Comment 3

[Conrad Carlen (not reading bugmail)]

Simple to fix with EnsureProfileFileExists(). If we want this to be ensured
every time the file is requested at runtime, the nsIDirectoryServiceProvider in
profile mgr would have to request these locations not be cached by
nsIDirectoryService. It would be a performance hit not to cache. Otherwise, we
can do the Ensure bit only the first time the file location is requested.

Comment 4

[Conrad Carlen (not reading bugmail)]

Attachment: patch to ensure files exist

Comment 5

[Conrad Carlen (not reading bugmail)]

The above patch uses EnsureProfileFileExists() whenever asked for a file in the
list above. Since it does this, I don't think it needs to copy those files from
defaults after migrating a profile. Bhuvan, Seth - Can you review?

Comment 6

[racham]

Conrad,

Looks like you missed Ensure stuff for history file..or did I miss it..?

bhuvan

Comment 7

[Conrad Carlen (not reading bugmail)]

The history file starts out as blank and is made by history if needed. It's
unlike the others which are taken from the defaults and then modified.

Comment 8

[racham]

that's right...silly question.. sorry about that..

go for it. r=racham

Comment 9

[Conrad Carlen (not reading bugmail)]

Alec, can you sr?

Comment 10

[Alec Flett]

sr=alecf

Comment 11

[Conrad Carlen (not reading bugmail)]

Fix checked in. To verify: Run the browser and quit. Delete any of the files:
bookmarks.html, localstore.rdf, mimeTypes.rdf, panels.rdf, or search.rdf. Run
the browser again and any of these files will be copied from the defaults if
they were missing.

Comment 12

[timeless]

um. in nc4 you could pick a bookmarks file to have any file name and live 
anywhere.  If mozilla still supports that preference string, could you alter 
the bookmarks code to check that filename first?  If i use c:\icqlinks.html and 
my profile is in c:\profile\mozilla, then i don't want another bookmarks.html 
copied to c:\profile\mozilla.

I'm sorry I didn't mention this earlier.  I'll let someone else file a bug that 
is easier to understand than this comment ...

Comment 13

[Conrad Carlen (not reading bugmail)]

timeless: This bug has nothing to do with whether the user can specify a custom
location for the bookmarks file. mozilla has never done that as far as I can
remember. bookmarks.html has *always* been copied from defaults when a new
profile is made. Maybe an RFE but another bug altogether.

Comment 14

[Grace Bush]

verified on trunk 2001020604