Make sure that certain Profile files exists all the time

VERIFIED FIXED in mozilla0.8

Status

defect
P3
normal
VERIFIED FIXED
19 years ago
3 years ago

People

(Reporter: racham, Assigned: ccarlen)

Tracking

Trunk
mozilla0.8
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Reporter

Description

19 years ago
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.
Reporter

Comment 1

19 years ago
(cont...) and that mechanism should be used to apply to makesure we copy a
default profile file into that profile fodler.
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.  
Status: NEW → ASSIGNED
Reporter

Updated

19 years ago
Summary: Make sure all certain Profile files exists all the time → Make sure that certain Profile files exists all the time
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.
Target Milestone: --- → mozilla0.8

Updated

19 years ago
Blocks: 64833
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?
Keywords: review
Reporter

Comment 6

19 years ago
Conrad,

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

bhuvan
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.
Reporter

Comment 8

19 years ago
that's right...silly question.. sorry about that..

go for it. r=racham
Alec, can you sr?

Comment 10

19 years ago
sr=alecf
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
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

19 years ago
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 ...
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.
Keywords: review

Comment 14

19 years ago
verified on trunk 2001020604
Status: RESOLVED → VERIFIED

Updated

18 years ago
No longer blocks: 64833
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.