since last update: library randomly gone after close/reopen

I do not know how to recreate this or what is happening but since the last update, on several occasions I have closed the library after working on zotero (standalone, Mac) and the next time I open it, the library is empty. I have restored the library and repeated whatever work I had done (painful) but cannot find any answer as to why this happens. I have checked database integrity and it returns no errors. I get no errors while working. I see the prior db with my data relabeled as "zotero [conflicted 2].sqlite" and a new, empty one in its place. I see files such as "zotero [conflicted 88].sqlite-journal" but do not know what to do with these. It is extremely frustrating to spend 3 hours working only to find that work erased. I have found no info on this. I have been using Zotero for years without problem. This just started. Please help. thanks, jeff
  • edited April 28, 2020
    This has nothing to do with an update. You have your data directory in a cloud storage folder, which will corrupt your database. (This has always been the case, and the same applies to any database-backed program.) Those "conflicted" files are created by the cloud storage service, not by Zotero.

    Close Zotero, restore to a working version of the database (using the service's cloud version history), verify that your data is correct in Zotero, and then close Zotero and move your Zotero data directory back to the default location immediately. When you restart Zotero, it will notice that the data directory is missing at the custom location and offer to use the default location instead.
  • (Also, out of curiosity, what service were you using, and does the service's name appear in the file path? Zotero will already warn you if "Dropbox" appears in data directory path, and in the next version we're extending that to "Google Drive", "OneDrive", and possibly iCloud Desktop/Documents if we can detect those, but if there are other common names it'd be good to know.)
  • This completely clarifies. My Zotero data is local on my Mac but I sync it to pCloud for a backup. I discovered late last night that if I simply take the conflicted copy of the database and rename it zotero.sqlite, when I open everything is just fine. Why pCloud is doing this now, I don't know. But I do know that nothing is lost, there is nothing wrong with Zotero and that I need to search elsewhere to figure out why suddenly pCloud is misbehaving. Thank you so much!
  • So this was in a "pCloud Drive" folder? Again, we're trying to determine if there are other strings we should look for in the path that we should warn about.
  • No, the data directory is NOT in a pCloud drive folder, just a regular folder on my Mac Air harddrive. However, I have it set to sync with pCloud (copies to a cloud folder I designate) and that must be how, someway or another, it is generating these (i.e., when there is a sync conflict, it puts the conflict log into the cloud drive but this, in turn, gets copied/synced on the local drive also). I wish I could explain! But it MUST be the sync causing the problems. Once I rename the putatively conflicted sqlite file 'zotero.sqlite' everything goes back to normal.
  • Not sure if this problem has somehow been resolved, other than turning off pCloud folder sync? I have the same problem: pCloud allows you to sync local folders into its cloud storage. It seems to scan for changes to the file content and does seem not take into account whether a file is in use or not. I have conflicted copies of both zotero.sqlite and zotero.sqlite-journal in my online synced version of the Zotero folder.
  • @rickus: Under no circumstances should you have your Zotero data directory in cloud storage.

    https://www.zotero.org/support/kb/data_directory_in_cloud_storage_folder
  • And whether it's in a dedicated cloud storage folder or you've set up pCloud to sync an external folder doesn't make a difference. If you're getting conflicted copies of the database, by definition the cloud storage tool is writing to the file, and the same warnings apply.
Sign In or Register to comment.