View Single Post
Old 03-29-2010, 01:38 PM   #46
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: 26,433
Karma: 5383257
Join Date: Oct 2006
Location: Mumbai, India
Device: Various
Quote:
Originally Posted by chaley View Post
I am part of a multi-country multi-partner project at my university, and we use dropbox to share code and papers under construction. We have frequently (several times per week) had cases where changes were simultaneously made to a file in different dropboxes. The result was the creation of 'conflict' files, all of which needed to be manually examined to determine which one was correct. In a couple of cases, neither were correct; we had to merge them together.
Interesting (and slightly horrifying) use for dropbox, why don't you use a version control system?

On the question of robustness. I'm not a dropbox user and I really don't know too much about it, but as Starson17 pointed out, calibre relies on an sqlite database. I would be rather surprised if dropbox was able to handle concurrent changes to the database file, which to it is presumably an opaque binary blob.

In addition, consider the following scenario of two users making concurrent changes to the same calibre library.

User 1 changes the author name of an entry. This updates the db for user 2. calibre does not rescan the db everytime the file changes, so User 2's calibre instance will continue to happily use its cached data. Now suppose user2 also decides to edit the same author name. calibre2 will use the old author name before user1's edit and will therefore not be able to find the files fo that book, since the file location depends on the author name. It will therefore think that entry has no files and create a new folder for that book with no files in it.

Now when dropbox syncs, both users will have lost the files of that entry, which will be in an orphaned folder based on the author name user 1 chose.

I can think of lots of problems like this caused by concurrent edits. Really the only safe way to support concurrent editing is with row level locking, the way it is done in databases.

So please dont use multiple calibre instances on the same dropbox share concurrently, or I am going to be dealing with a lot of reports about missing files
kovidgoyal is online now   Reply With Quote