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.
(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
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
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?
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.
that's right...silly question.. sorry about that.. go for it. r=racham
Alec, can you sr?
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.
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.
verified on trunk 2001020604
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.