Thread: Calibre Library Accessed from Multiple Devices
View Single Post
Old 02-25-2018, 12:37 PM   #24
haertig
Wizard
haertig ought to be getting tired of karma fortunes by now.haertig ought to be getting tired of karma fortunes by now.haertig ought to be getting tired of karma fortunes by now.haertig ought to be getting tired of karma fortunes by now.haertig ought to be getting tired of karma fortunes by now.haertig ought to be getting tired of karma fortunes by now.haertig ought to be getting tired of karma fortunes by now.haertig ought to be getting tired of karma fortunes by now.haertig ought to be getting tired of karma fortunes by now.haertig ought to be getting tired of karma fortunes by now.haertig ought to be getting tired of karma fortunes by now.
 
Posts: 1,898
Karma: 31522252
Join Date: Sep 2017
Device: PW3, Fire HD8 Gen7, Moto G7, Sansa Clip v2, Ruizu X26
Quote:
Originally Posted by kovidgoyal View Post
... all characters used in filenames in the library are safe on all filesystems ...
I thought the parenthesis used were a problem with Google Drive, causing corruption if you try it with that cloud storage provider. Granted, Google Drive is not a technically "filesystem".

Quote:
The only thing that is not multi-user safe is exporting the calibre library folder and running multiple copies of calibre on it on different computers, i.e. the calibre GUI is not multi-user safe in that you cannot run multiple instances of the GUI on the same library at the same time.
I thought you couldn't run the Calibre GUI, and the content server at the same time. You could run the content server from within the GUI, but not as a separate program. I thought I remembered reading somewhere that if you have the content server running, you have to kill it, run the GUI, kill the GUI, then restart the content server when you're done. Or just leave the GUI running 24x7 and run the content server from within.

What I have done is use the GUI on my main library. Nobody else gets access directly to that. And then I rsync that main library to a separate server daily, and run a content server against that rsynced copy. I don't want any user to be able to make changes - I only want them to have read access. But if they somehow manage to change something, because I configured the content server incorrectly, I don't really care too much because their changes will be overwritten by the next rsync. This seems to work very well.

However, I just read the other day that you should not run the GUI and an rsync at the same time. I have not taken that into consideration in my rsync scheme. So far I haven't had any problems (that I am aware of!), but that may just be luck. I will investigate creating a snapshot and rsync from that in the future. Or I could enhance the rsync scripting strategy so that it that kills any running GUI before starting the actual rsync command. I didn't realize that concurrent rsync copying would be a problem, until I just ran into a comment about that recently.

As always, thanks again to Kovid for giving us such a wonderful program!

p.s. - I'm thinking I need a safer strategy for the rsync. If I don't go with snapshots, maybe something like this:
  1. Kill any running GUI on server A
  2. chmod 000 the GUI executable on server A (for extra protection from me trying to start it up manually!)
  3. Kill the content server on server B
  4. Run the rsync
  5. Restart the content server on server B
  6. chmod 555 the GUI executable on server A

My current implementation is this. I now see that what I am doing could potentially cause problems:
  1. GUI may or may not be running on server A (probably not, but could be)
  2. Content server is definitely running on server B
  3. Invoke rsync (started on server B, this pulls content from server A's rsyncd daemon)
  4. Kill/restart content server on server B to force it to re-index (or whatever) any new content
haertig is offline   Reply With Quote