Open Alexander-jb opened 3 years ago
sienori
commented
3 years ago I'm sorry for the inconvenience, and I apologize for the delay in replying. Unfortunately, we don't have a way to restore sessions from a corrupted sqlite file... https://github.com/sienori/Tab-Session-Manager/issues/421 I recommend enabling the local backup or cloud sync option. I'm also looking for a better way to do backups. https://github.com/sienori/Tab-Session-Manager/issues/641
klorinczi
commented
3 years ago I'm sorry for the inconvenience, and I apologize for the delay in replying. Unfortunately, we don't have a way to restore sessions from a corrupted sqlite file... #421 I recommend enabling the local backup or cloud sync option. I'm also looking for a better way to do backups. #641
A regular backup of sqlite db would be a good idea...
Alexander-jb
commented
3 years ago So I am not convinced that my .sqlite file is actually corrupted. I can run it through a DB Browser and test it and it never comes back with any error or 'corrupted' response. I am currently pursuing ways of accessing the information contained in it, so would appreciate any info you have on accessing data in the .sqlite assuming it were just normal/not corrupted.
Given that (as I and others have already said) the existence of this bug, however rare, undermines the utility of this entire extension for anything other than very short term storage from one session to the next, the existence of this bug needs to be noted in the extension description--provide a warning that it is NECESSARY to do backups if you intend to not lose data saved with this extension. Given that you KNOW that this bug is out there and risks erasing users data, leaving it open to chance by not warning prospective users upfront is simply negligent.
Likewise, as klorinczi notes above me, it seems that there is a simple short-term solution: have the extension store regular backups of the .sqlite file alongside the one that it uses. It seems that you could even have it create a number of backups at intervals, maxing out and replacing the oldest backup at a set # of files. Basically an internal time-machine like function since you are aware that this tendency for corruption/file loss exists.
Seems to me that this feature would likely prove helpful even once this bug is resolved.
As mentioned in my previous thread (https://github.com/sienori/Tab-Session-Manager/issues/670), I lost many months worth of accumulated research data/saved sessions on December 6th, a tremendously upsetting number of hours and effort gone in an instant due to the well-established disfunctionality of this extension. I uninstalled and reinstalled TSM, and now have basic functionality of the extension again--i.e., it saves regularly, saves session on closing, etc. Old lost sessions, however, remain gone.
Additionally, I have been playing around with the files in the /storage folder for the extension to see what happens to current sessions when I move or delete files in the /idb and /ssensosi folders. Deleting and replacing the new ssensosi.sqlite makes the new sessions disappear and then reappear. Messing with any one particular number file in the /ssensosi folder appears to mess up the ability for the extension to retrieve any of them for some reason, and I get 0 sessions when I look at TSM. When I paste the missing session back, all sessions return.
However, none of this seems to apply with my old ssensosi.sqlite file or any of the number files in the /ssensosi folder when I replace those in the storage folder with them. I have tried doing this for each file and in many combinations. Is there any means of my retrieving the information stored in these files by other means, even if it involves just reading through a database? I cannot even determine what format these number files in the /ssensosi folder are--it seems to just be a text file of some kind? I am desperate and really cannot understand why the developer of this extension has failed to provide any assistance for this bug, despite having posted an update to the extension since my original post.
Any help on accessing the data stored in these files by any means, even if it is tedious, would be greatly appreciated. And of course any guidance on other approaches to restoring these files other than those outlined in the IndexedDB Error wiki would also be great if anyone has had any luck by other means.
Thanks for any and all help in resolving this issue. I would love to see the developer of this extension take a more active role in redressing this critical bug, but so far there has only been a shameful silence.