Chrome FileSystemStorage writer:onerror() throws exception => entire ebook library gets deleted?

[danielweck]

Niclas Bergstrom (ReadSpeaker) reported a critical bug in the Chrome extension: all EPUBs in library disappear, when opening / unzipping another EPUB (sorry, the ebook is private).

This bug seems to have been inadvertently fixed by @ryanackley 's checkin: 31e55f5#diff-e8922b404eb71403f6ad6457d4449a4fR38

...which addressed a different issue: #280

My personal observation is that the thrown exception in FileSystemStorage writer:onerror() was the culprit of the ebook library deletion, but am I right? Is there a risk of further similar issues, or have we now plugged the hole for good?

[rkwright]

Agreed. We can hope it was fixed but I would be more comfortable if we knew why the exception nuked the library.

[ryanackley]

The fix for #280 kind of fixed it but it would have happened again if something else were to cause an error while writing. Deduced the problem and fixed it.

[danielweck]

Thanks Ryan! :)

[danielweck]

New bug report:
http://idpf.org/forum/topic-2447
We are waiting for the forum user to share the cultprit EPUB, so at this stage we are not sure that this is a related issue.

Meanwhile: are there other API callbacks that need try {} catch() {} 'ing to ensure that EPUB import failures cannot destroy the ebook library? Or is could that be a case of FileSystemStorage writer:onerror() (or similar failure condition) that results in incomplete / dirty database update+close? (or filesystem index corruption)

[danielweck]

Related issue:
#329
(more robust database storage)

[danielweck]

Related issue:
#328
(ebook recovery when index gets corrupted)