User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060317 Firefox/1.6a1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060317 Firefox/1.6a1 I get an assertion failure window as soon as the browser starts. If I click OK a browser window opens. So far the browser appears to be functioning properly otherwise. Here is the top of the message: ASSERT: Can't serialize: file doesn't exist! Stack Trace: 0:ENSURE_WARN(false,Can't serialize: file doesn't exist:, 2147549183) 1:SRCH_ENG_serializeToFile() 2:SRCH_SVC_convertSherlock([object Object],rpmfine) If you wan't the rest of the stack trace let me know, but I have to type it in from a screenshot. Reproducible: Always Steps to Reproduce: Start browser

Do you get this every time you start up? Can you send me the contents of your profile's searchplugins directory?

You could also try setting the browser.search.log pref to true and checking STDOUT or the Javascript console for messages.

Daniel, are you still seeing this? If so, could you try some of the things mentioned in the previous comments?

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060317 Firefox/1.6a1 ID:2006031704 I saw this message several times after updating but it does not appear any more.

Ah, so those attachments show that the initial conversion failed, but the renaming of the files still worked. Sounds like there is something wrong with my backup code on linux. Flummox: Can you try renaming the .xml files you attached to .src, and running Firefox again? You should get the error messages again. The JavaScript console log from that run will show the actual bug and not the side effects, so if you could attach that I'd appreciate it.

Actually, you don't need to test, I think I found the problem. The Linux nsIFile implementations seem to not change "this" after a moveTo or copyTo, while the Windows one does.

(which I've just realized is bug 200024)

The first hunk is just code simplification.

Comment on attachment 215730 [details] [diff] [review] patch >Index: browser/components/search/nsSearchService.js >+ // Set aEngine._file explicitly, since some moveTo implementations don't >+ // change srcFile (and thus aEngine._file) to point to the new file >+ // (bug 200024) >+ aEngine._file = xmlFile; Actually, I'll remove this comment. Setting _file explicitly will always be correct, regardless of bug 200024's resolution. Even if nsLocalFileUnix is changed to match Windows, relying on that makes code hard to follow, so this comment would serve no purpose.

Comment on attachment 215730 [details] [diff] [review] patch bitrotted by the patch in bug 330887

Comment on attachment 215730 [details] [diff] [review] patch this still applies, and shouldn't be blocked by bug 330842

Comment on attachment 215730 [details] [diff] [review] patch Ok, though I don't see how oldFile/newFile is measurably improved by changing to srcFile/xmlFile. how about originalSherlockFile and newSearchFile, in line with the recent discussions on better var names?

checked in branch and trunk mozilla/browser/components/search/nsSearchService.js 1.1.2.8 mozilla/browser/components/search/nsSearchService.js 1.9

Checkin for this bug may have caused a 15% increase in number of allocations on balsa. See bug 333173.