Thread: Elipsa Ghost eBook Purchase on an Elipsa
View Single Post
Old 07-23-2021, 03:02 AM   #28
davidfor
Grand Sorcerer
davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.
 
Posts: 24,907
Karma: 47303748
Join Date: Jul 2011
Location: Sydney, Australia
Device: Kobo:Touch,Glo, AuraH2O, GloHD,AuraONE, ClaraHD, Libra H2O; tolinoepos
Quote:
Originally Posted by Cootey View Post
I posted the clipboard error message and the 'PRAGMA integrity_check' results for you above. Was there anything else you'd need in the future?
There isn't much I can do with the results of the integrity check. I can tell from a quick look if they are likely to be fixed by doing a VACUUM. That will be the case if the errors are only in the indexes or with free space. With the results you have, I doubt it can be fixed.
Quote:
Since I began bumping into these issues, I don't run Kobo desktop and Calibre at the same time. Also, there are no active programs operating on the Kobo when I eject it. The Mac won’t allow it. I can’t even eject it if the Elipsa is simply the current directory in Terminal. I also plug the Elipsa directly into the back of my Mac instead of using a USB hub to eliminate potential issues there. I never have these problems with my Clara. I haven't treated my Elipsa any different, except now I treat it as if its made of handblown Egyptian glass when I bring it near my Mac.

I usually check the database first in Calibre before ejecting it. I may have forgotten to do that this time, but I’ve ejected directly from within Kobo Desktop before with no issues.

That all being said, since I last posted above I had to restore my Kobo. Due to our past conversation in another thread, I’ve been experimenting with using rsync instead of dd to make a backup. So I used cp to create the backup archive, then planned to rsync the archive back onto the Kobo in the event of a database corruption. I had a full disk image backup at the ready, so this was my first time to experiment using rsync to restore the Kobo.

While it was running, it deleted a ton of ._ files off the Elipsa. Usually, the Mac creates those files every time you access a directory from the Finder. However, there were ._ files in directories I had never accessed from Finder. To be clear, these were on the Kobo and didn’t exist in the backup. That’s why rsync removed them. That’s probably obvious to you, but I’m trying to be thorough. They were created between the time I made the backup and the time I ejected the Kobo.

So what process is accessing the Kobo? Prior to your suggestion, I was already puzzling over this. TimeMachine apparently can store data in ._ files, but I don't use TimeMachine on USB external drives. I blocked Spotlight from indexing the Kobo whenever it is mounted. Spotlight only indexes for searching, however. It doesn’t create ._ files. I have never seen this issue with any USB mounted device before, and I can’t be certain this is the issue that caused the corruption. The Kobo tends to ignore ._ files in my experience.
The corruption could happen from:
  • An application crashing doing during the write.
  • Two applications attempting to access the database at the same time.
  • Failing or otherwise damaged storage.
  • File system corruption by something.
  • Something making changes at the file system level.
  • Device being disconnected before all writes have been completed.

Unfortunately, I just don't know when it happens. A possibility is a background task on the MAC clashing. But, you should be able to see that.

Another thing to try is to not eject from within the applications, either calibre or the Kobo desktop. Close these and wait a couple of minutes. That should make sure nothing that you are doing trying to update, and it should let any caches flush as well. I don't know the MAC, but, Windows has, or at least had, an option for "fast eject" or something like that. Turning it on, meant that writes to removable media were immediate and not cached.

Quote:
This is a lot of text, but as I said above, I'm trying to be thorough. I know a couple of people have bumped into corrupt Elipsa databases. One person gave up and returned his Elipsa to the store. We should be finding out if they use Macs, Kobo Desktop, and Calibre to find commonalities. And the big question is: Why is only my Elipsa having these issues and not either of our Claras?
Unfortunately, there are always corrupt databases. But, the number with the Elipsa seems to be a lot worse. It might be something in the firmware. If it is, it will show when Kobo roll these updates out to other devices. Or it could be something about the hardware. There is enough different hardware in them (USB-C, multi-core CPU etc) that there might be something that they have missed. If it is caused by something during the connection to the PC, maybe it is one of the processes on the device not stopping cleanly and contending with the database access from the PC. The obvious culprit would be something in the note taking software. That is new and not on the other devices. And the only way to test that is to not use it for a while.
davidfor is offline   Reply With Quote