***Overview Description: When you migrate an existing 4.x profile your new Seamonkey profile does not contain the file search.rdf. I guess there is no such file to migrate from 4.x so it needs to be created. I believe this to be a regression but I think it may have been broken for a couple weeks. ***Steps to Reproduce: 0) Create a 4.x profile. 1) Launch Profile Manager and migrate an existing 4.x profile and launch. 2) In a navigator window select the toplevel Search menu and choose Search|My Sidebar Search Tab|Advanced. 3) Switch the the search sidebar tab and select the within 'All Engines' dropdown. ***Actual Results: The dropdwon is empty save for 'All Engines' and 'Edit Categories'. ***Expected Results: After those two items should be categories like 'Web', 'Music', 'Shareware', and 'Shopping'. ***Build Date & Platform Bug Found: This definitely shows up on all platform Branch builds 2000101608. ***Additional Builds and Platforms Tested On: I am currently blocked and have not been able to test this on trunk builds. ***Additional Information: I have not done an exhausitve search on migrated files or the complete ramifications of this missing file. I just know that these categories are missing and it's because the search.rdf file is missing (normally located in each profile directory).
You're right, if there's no search.rdf file in the original profile (and there won't be since 4.x never had a search.rdf file) it won't be migrated. This is the same problem that occured with mimetypes.rdf. Bhuvan checked in a fix for that bug. I'm reassiging this to him since I believe this closer to a profile management bug than a migration bug. Although IMHO these types of bugs belong to the groups that are supposed to use these files (i.e. whoever depends on mimetypes.rdf and search.rdf). Those groups should be creating "default" versions of these files if they don't find them.
Assignee: dbragg → racham
this is broken on the trunk also(checked Win98) build 2000101608
Bhuvan, please reassign this to the search component. I think that's rjc. You should review the change.
Robert, Giving this to you so that Search Component can create/copy a new default search.rdf, if it does not exists in the user profile directory. This will be a better solution than changing the stuff in profilemanager code.
Assignee: racham → rjc
Ah, you know, search.rdf USED to be copied into the user's profile if it didn't exist... (migration or not)
I suspect this broke with ccarlen's checkin (Rev 1.110 of mozilla/xpfe/ components/search/src/nsInternetSearchService.cpp) when he switched the search code from using nsIFileLocator to NS_GetSpecialDirectory(NS_APP_SEARCH_50_FILE) as nsIFileLocator internally would copy over the default "search.rdf" into the user's profile directory if it didn't exist.
Racham, can you explain what's going on here? http://lxr.mozilla.org/seamonkey/source/profile/src/nsProfile.cpp#2074
Assignee: rjc → racham
I agree with Robert. I think we had some mechanism like that in FileLocations. I guess Conrad might have overlooked this. Robert, all that's happening there is that we constructing the path for serach.rdf file. So, what probably should also happen there is to check for the existentce of the file and copy one from default location if does not exists.
I spoke to Conrad. Passing it to Conrad..
Assignee: racham → ccarlen
The thing to do is to make the nsIDirectoryServiceProvider in nsProfile.cpp copy the default file over if it doesn't exist. Working on a patch.
Status: NEW → ASSIGNED
The above patch ensures that, when asked for the search.rdf file, the default file will be copied if the one in the profile dir doesn't exist. For consistency's sake, the same is done for the mimetypes.rdf file. This is better than just copying it over during migration because if the file is deleted, it will be restored.
Disregard the previous patch. It applied the same fix mimetypes.rdf. Since that was already fixed, doesn't need to be addressed here.
Simpler patch is dandy. r=rjc
patch id 17476 (second patch) -> r=racham
sr=waterson. are there any other files we'll drop on the floor?
No, the other files that were created if they didn't exist are handled during migration. The code which copies those 3 files, though, is a hack and needs to be replaced.
When you have a small, safe patch with r= and sr=, please put [rtm+] in the status whiteboard so the PDT knows to try and give you an approval.
rtm++ (ignore my previous comment, it was probably for another bug :-(
Whiteboard: [rtm+] → [rtm++]
Fix was checked into the branch. Waiting on the trunk because there is some code there which is supposed to be backed out. As soon as nsProfile.cpp gets back into forward motion, I'll check it in there.
Verified on the 10/31 branch Win, Mac and Linux builds.
Argh, I forgot this one. Will check it in soon.
Priority: P3 → P1
Target Milestone: --- → mozilla0.8
The patch which was checked into the NS6 branch was checked into the trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
verified on trunk build 2001010404
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.