50381 - search.rdf gets corrupted

Status: RESOLVED WORKSFORME

(SeaMonkey :: Search, defect)

Description

[Chris Waterson]

On Linux, I'm seeing my search.rdf file get corrupted. I debugged a little bit
and discovered that the search service is getting held on to until XPCOM
shutdown, and then trying to flush the datasources. Writing it out at this
points requires us to get *other* services, which fails.

I'll try to fix this by making the RDF/XML datasource hold on to the services it
needs to write out stuff...

Comment 1

[Chris Waterson]

Nominating for nsbeta3: this causes you to lose all your search settings.

Comment 2

[Chris Waterson]

Attachment: safety checks in nsRDFXMLDataSource.cpp

Comment 3

[Chris Waterson]

The above patch

1) checks to make sure we're not in XPCOM shutdown before re-writing an RDF file
2) ensures that we create valid RDF/XML even if an error occurs during
processing (and hopefully will at least write *more* of the user's data out in
the event of some bizarre failure).

I applied this patch, and now see that we are failing to write out search.rdf
*at all*. (Interestingly, I don't see the default search stuff being installed
as part of migration, either...)

I think we should check this in, and then rjc should look at why the search 
datasource thinks that it's dirty.

racham may be able to tell us why search.rdf is not being installed, even though
there is a default search.rdf available in $(DIST)/bin/defaults/profile.

Comment 4

[racham]

Chris,

I see the search.rdf getting installed into the new profiles that are created 
via profile manager's CreateProfile UI. I checked this with this morning's trees 
pulled on my windows and linux machines.

The reason why search.rdf is missing from the migrated profile is that we don't 
do a recursive copy of default directory over there...as on some platforms, 
files get overwirtten (bad case is bookmarks.html) and on some platforms we 
don't overwrite but ignore. So, if we do a recursive copy before migrating the 
4.x profile contents some platforms leave bookmarks file untouched and user does 
not see his/her 4.x profiles. IF we decide to dump all default file after 
migration we overwrite valid files.

So, for such an situation in the past, we hacked our way for panels.rdf. In the 
profile manager 
(http://lxr.mozilla.org/seamonkey/source/profile/src/nsProfile.cpp#1567, we 
never had our required API implemented in nsIFile. Now Conrad is trying to add a 
recursive copy routine in the profile manager. So we can enhance this routine 
to take additional boolean param that says overwrite or not to overwrite), we 
have code to drop panels.rdf file into the migrated profile directory. May be we 
should create such an hack for search.rdf also for now, though I don't that 
solution very much as we need to keep doing these hacks.

Comment 5

[Robert John Churchill]

r=rjc on the safety checks  ("goto"s and all)

Comment 6

[Chris Waterson]

rjc, checked in  safety stuff. If you get a chance to debug why we're holding on
to that data source so long, that'd be great...

Comment 7

[Daniel Veditz [:dveditz]]

Sounds like the corruption problem is solved, does the remaining issue need to 
be done prior to beta3?

Comment 8

[Daniel Veditz [:dveditz]]

No response, guessing not.

Comment 9

[Daniel Veditz [:dveditz]]

This milestone has passed, setting to default so it'll show up in 
appropriate queries

Comment 10

[Marcia Knous [:marcia]]

Netscape nav triage team: as per Matt Fisher's pre-triage recommendation, this 
bug is nsbeta1-.

Comment 11

[Jeremy M. Dolan]

Dunno if this issue was fixed, waterson says he checked in something, and no
activity for 7 months.

This (or something similar) is still happening. I've opened bug 87699 on it a
while ago.

Comment 12

[Samir Gehani]

-> Future.

Comment 13

[Arun Prasannan (polar)]

This bug is being marked EXPIRED as it has seen no activity in a very long time.

If you think that the issue reported might still be relevant, please test with a recent release of SeaMonkey and if the problem persists feel free to re-open the report. Thank you.

http://www.seamonkey-project.org/

Comment 14

[Mark Banner (:standard8)]

Bulk reopening incorrectly expired bugs - no activity does not constitute no bug - these need proper checking.

Comment 15

[Robert Kaiser]

I haven't heard or seen such problems in recent years, let's make this bug go away.