Closed Bug 487560 Opened 15 years ago Closed 15 years ago

if Snowl bookmarks are deleted, Snowl does not recreate them

Categories

(Mozilla Labs :: Snowl, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: myk, Unassigned)

Details

If for some reason Snowl's "bookmarks" are deleted from Places, Snowl does not recreate them, so the list and river views are suddenly empty, and you can't use them anymore.

I noticed this today when something (probably Weave) deleted all my bookmarks.  It seems like Snowl should check Places when you open a view that depends on it to make sure it's up-to-date and update it if it isn't.
upon startup, snowl tests for its internal structure by checking the snowl root anno (and also the version and rebuild complete flags stored on the anno - which guards against incomplete rebuilds); if the root is found, init is set and no rebuild needs to happen.  so in the case of a failure in the sqlite db or failure to restore from .json, snowl will rebuild its places db.

what must have happened in your errant weave behavior was a deletion of non readonly bookmarks.  were the Places root folders like Bookmarks Toolbar there even though bookmarks weren't?  or snowl Source/Authors, which were empty?

in such an edge/bug case i'm not sure what an auto algorithm should be.  at some point i was going to add a menu option to rebuild/restore the places db, and think this is the better solution.  

even better would be to take advantage of places restoring from .json, which would/should have restored snowl items if the sqlite db had to be recovered.  when does bookmark backup from .json happen in Places if it thinks bookmarks need to be restored?
(In reply to comment #1)
> what must have happened in your errant weave behavior was a deletion of non
> readonly bookmarks.  were the Places root folders like Bookmarks Toolbar there
> even though bookmarks weren't?  or snowl Source/Authors, which were empty?

Unfortunately, I don't recall whether the Bookmarks Toolbar or Bookmarks Menu folders were present.


> in such an edge/bug case i'm not sure what an auto algorithm should be.  at
> some point i was going to add a menu option to rebuild/restore the places db,
> and think this is the better solution.  

This seems like an implementation detail that Snowl should take care of automatically rather than something we should expose to users (although it's fine to have a hidden option).  Is it not possible to detect that Snowl's Places root is out of sync with its database?


> even better would be to take advantage of places restoring from .json, which
> would/should have restored snowl items if the sqlite db had to be recovered. 
> when does bookmark backup from .json happen in Places if it thinks bookmarks
> need to be restored?

Places backs up bookmarks automatically on a regular basis (I think daily).  But my last backup didn't contain any snowl: URLs, nor does one I create now (although that may be because they've all been wiped out).
I don't know if this is related, but I deleted a source from my list and then a whole bunch of sources disappeared, when I tried to re-add one of the sources that were missing, Snowl told me that it was already in my list.

And since the new river only shows feeds from selected sources I can no longer see the feeds from the invisible sources!

This was in version 0.3pre1d200904092229.
(In reply to comment #2)
> (In reply to comment #1)
> 
> This seems like an implementation detail that Snowl should take care of
> automatically rather than something we should expose to users (although it's
> fine to have a hidden option).  Is it not possible to detect that Snowl's
> Places root is out of sync with its database?

no, root cannot know state of items in its tree, if removed by a non snowl process.  a top to bottom check of each record would have to be done at startup.  at some point a database integrity/cleaner tool will be made (that's why we added placeId).  but running this at startup might be too expensive vs. a user initiated action if necessary.
> 
> 
> > even better would be to take advantage of places restoring from .json, which
> > would/should have restored snowl items if the sqlite db had to be recovered. 
> > when does bookmark backup from .json happen in Places if it thinks bookmarks
> > need to be restored?
> 
> Places backs up bookmarks automatically on a regular basis (I think daily). 
> But my last backup didn't contain any snowl: URLs, nor does one I create now
> (although that may be because they've all been wiped out).

just to clarify, custom View items are backed up to .json, but snowl root and author/source records are not, as in any restore scenario we want to rebuild from the snowl db which is the master.  so the path here is 1) snowl root was found and verified, so no rebuild; or 2) root was not found but an error occurred and rebuild did not happen.
(In reply to comment #3)
> I don't know if this is related, but I deleted a source from my list and then a
> whole bunch of sources disappeared, when I tried to re-add one of the sources
> that were missing, Snowl told me that it was already in my list.
> 
> And since the new river only shows feeds from selected sources I can no longer
> see the feeds from the invisible sources!
> 
> This was in version 0.3pre1d200904092229.

@Keith - were there any errors in the console?  i assume when you upgraded to 0.3pre you went through the conversion to Places process successfully, no?  if you rename your [profile]\places.sqlite and restart, a snowl db rebuild should happen and all items should be restored (your bookmarks as well, from last .json file backup).  then could you try again to remove a source and report what happens..  thanks for helping test.
oh, and if you set pref:
extensions.snowl.log.appender.console.level
to Info, you will see some more verbosity in the console..
alta88:
I get a console error: "oTidyBrowser is not defined" in Line 220.

I did upgrade to 0.3pre and the conversion happened successfully. I renamed my places.sqlite and it had no discernible effect on my Snowl Sources List.

I did find however that when I export my opml file that all my sources are visible, so my next more will be to uninstall Snowl, reinstall it and restore my sources. I'll delete a source again and see if it happens again.
Okay, so that didn't work at all. All my sources just stayed as they were after un/reinstall :(

How can I forcibly remove all my sources? Not through deleting them from the list, because I can't delete them all.

And how can I copy my whole console so I can show you guys? Because I don't know which errors/warnings/infos are relevant :/
@Keith - that message is unrelated afaict.  if you shut down Fx, rename places.sqlite and restart, a rebuild must happen, otherwise something is very odd.  

if you have Console2 (https://addons.mozilla.org/en-US/firefox/addon/1815) you can multiselect console messages by shift click, and copy them. perhaps you can post them all here.

do you have a lot of extensions?  could you try on a clean profile - all you would need to do is copy messages.sqlite into your new/clean profile to have all your snowl sources available there.  are you able to subscribe to new sources?

alternatively, perhaps you could zip up messages.sqlite, i'm not sure how big it may be, and maybe email it to me.
(In reply to comment #4)
> (In reply to comment #2)
> > This seems like an implementation detail that Snowl should take care of
> > automatically rather than something we should expose to users (although it's
> > fine to have a hidden option).  Is it not possible to detect that Snowl's
> > Places root is out of sync with its database?
> 
> no, root cannot know state of items in its tree, if removed by a non snowl
> process.  a top to bottom check of each record would have to be done at
> startup.  at some point a database integrity/cleaner tool will be made (that's
> why we added placeId).  but running this at startup might be too expensive vs.
> a user initiated action if necessary.

Can't Snowl at least listen for notifications regarding changes to places?  If it really can't know when its Places records are modified outside of Snowl, then that seems like a pretty significant drawback to using Places in this way.  At the very least, it should be possible to check that the number of Snowl places is equal to the number Snowl expects there to be, although this is a poor substitute for knowing that those places are the correct ones.
i'm going to mark this resolved, as there have been many changes to places build code.  in addition, there is now a menuitem to rebuild places, should a rare/rogue process affect snowl places in a way it can't auto recover.

please reopen if an issue is detected.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.