View Single Post
Old 05-26-2010, 08:45 PM   #28
kovidgoyal
creator of calibre
kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.kovidgoyal ought to be getting tired of karma fortunes by now.
 
kovidgoyal's Avatar
 
Posts: 45,423
Karma: 27757236
Join Date: Oct 2006
Location: Mumbai, India
Device: Various
Wait a sec, I think I get it. You're saying that because you're keeping your metadata.db on a networked storage backend that doesn't support file locking you're worried your database will get corrupted?

Your database will only get corrupted in this scenario if you are performing concurrent writes to metadata.db and in that case you have much larger problems to worry about than metadata loss. You could lose the book files themselves.

For example when you change author or title calibre moves books into a new folder based on the new author and title. Now if you happened to concurrently change the metadata in two calibre instances that are using the same metadata.db, you will end up losing the book files (as well as the little OPF file if it existed).

calibre's current code base just isn't deigned to handle concurrent write access. Adding distributed metadata is not going to fix that.
kovidgoyal is online now   Reply With Quote