Updating metadata deletes mobi/epub

[JSWolf]

NEVER EVER USE AN OFFLINE STORAGE DIRECTORY FOR YOUR WORKING CALIBRE DIRECTORY.

All it does is cause things not to work.

[webmaven]

Originally Posted by DoctorOhh

This is your problem. Unless you pause syncing, anytime you edit metadata you risk misplacing books. These books aren't actually deleted. When the metadata got updated a new folder was written with the correct title / author and since your book was locked (for some reason) it was never moved to the new location.

It's worse than that, actually: Because Dropbox (and, I assume, many other file-syncing tools/services) are case insensitive in order to be Windows-friendly, even when the file isn't locked a case change anywhere in the path (so for example in the title or author metadata fields) will cause a write conflict with the remote version, which Dropbox will resolve by creating an additional copy of the book/author folder (marked with (Case Conflict) appended to the folder name).

The reason it is worse is that pausing the syncing doesn't prevent the problem!

The case conflict can be avoided if you do case-change renames (of either authors or titles) as follows:

1. rename Mcname to McName_
2. Wait for Dropbox to sync
3. Rename McName_ to McName

This is essentially a high-latency two-phase commit, and a PITA.

This song-and-dance isn't necessary if you're changing anything other than (or in addition to) the case (eg. removing extra spaces, swapping title and author, removing or adding punctuation, correcting a misspelling, de-ASCII-fying, etc.).

[DoctorOhh]

Originally Posted by webmaven

It's worse than that, actually: Because Dropbox (and, I assume, many other file-syncing tools/services) are case insensitive in order to be Windows-friendly, even when the file isn't locked a case change anywhere in the path (so for example in the title or author metadata fields) will cause a write conflict with the remote version, which Dropbox will resolve by creating an additional copy of the book/author folder (marked with (Case Conflict) appended to the folder name).

In 8 years I have never had a "Case Conflict" in Dropbox. You do get "Conflicted Copy" appended to the end of a filename when you fail to let Dropbox fully sync before using calibre. This happens when you update a file on one machine and then log into a second machine and start using calibre before Dropbox can fully sync. Is is part of the hazard of using Dropbox.

If I were to make 20 changes to calibre on machine 1 then went to machine 2 and started calibre before the metadata.db file were to sync, then the database would reflect the state of calibre before I made those 20 changes. The actual changes would actually exist in the file structure. Logging out then allowing Dropbox to fully sync will update all of the folders and files. Once Dropbox syncs you simply have to go into Dropbox and revert a copy that was timestamped when you last logged off of machine 1.

Originally Posted by webmaven

The reason it is worse is that pausing the syncing doesn't prevent the problem!

Pausing sync will prevent the OPs original problem with updating metadata from happening. Not allowing Dropbox to sync fully before shutting down machine 1 or before using calibre on machine 2 will cause the problems you describe. But this is easily avoided.

Originally Posted by webmaven

This song-and-dance isn't necessary if you're changing anything other than (or in addition to) the case (eg. removing extra spaces, swapping title and author, removing or adding punctuation, correcting a misspelling, de-ASCII-fying, etc.).

Allowing Dropbox to sync is always necessary and pausing sync during all metadata edits is also always required if you want to avoid the issues the OP was experiencing. As others have stated if you are not comfortable understanding exactly what is going on then storing your library out of the cloud folder and doing a once a day sync when you are not actively using calibre is probably best.