|
Yes, I *know* it's because of file locking.
I am asking two things:
1) Why is Calibre opening the file, replacing the contents, closing it (At which point Dropbox steps in and tries to read it) and then Calibre tries to open it *again* a split second later? Why does Calibre not just keep it open while changing it, which would result in Dropbox waiting?
Like I said, this isn't happening because I repeatedly change the metadata of a single file, and I'm getting caught because my previous edit hasn't been uploaded yet. I would understand *that* happening, and be recommending solution #2 below. But that *doesn't* happen.
It's happening when I edit the metadata of a bunch of books at once. Which means, as far as I can guess, that Calibre is opening and closing metadata.opf from 1-20 (in order?), and dropbox starts reading them...and then Calibre opens *all those files again*, presumably in order again, and thus trips over Dropbox, which had made it to file number 8 or whatever.
Why is opening files again?! What is this second pass that trips over anything that is reading recently modified files?!
2) Considering this weird double-update system that Calibre seems to want to use of editing files, if Calibre can't open a file, why can't Calibre just *move that update request to the end up of the queue* instead of throwing an error, and thus try again a second later?
Or, heck, write out a metadata.opf.new file and move it over a second later?
|