Upgrade StorageDirectory structure WebDAV
Zoteros Desktop client hard-codes a 'zotero' directory in a user-defined WebDAV URL but never uses this directory, but synchronizes with the URL's root.
For example, if the editable part of my WebDAV URL is http://zotero.example.com (*)
all the zip and prop files will be created in the root of this address - not in http://zotero.example.com/zotero/. Even not, when manually creating this 'zotero/' sub-directory, deleting all other files and enforce a reset - files are always repopulated in the URL's root.
Up to now, this was not exactly a problem for me (despite being counter-intuitive). But now I'm using a new mobile client (Zoo for Zotero), the first one supporting WebDAV synchronisation. He is seemingly unable to access the files (but can successfully authorize) on my WebDAV server (Cannot find 'AB24WHATEVER.ZIP'). This could be also a problem with the client (I'm working with the developer in parallel to settle this). But I would like it, to have the original glitch out of the way.
(*) btw, https is not working with self-signed certificates as provided by "Let's encrypt"
For example, if the editable part of my WebDAV URL is http://zotero.example.com (*)
all the zip and prop files will be created in the root of this address - not in http://zotero.example.com/zotero/. Even not, when manually creating this 'zotero/' sub-directory, deleting all other files and enforce a reset - files are always repopulated in the URL's root.
Up to now, this was not exactly a problem for me (despite being counter-intuitive). But now I'm using a new mobile client (Zoo for Zotero), the first one supporting WebDAV synchronisation. He is seemingly unable to access the files (but can successfully authorize) on my WebDAV server (Cannot find 'AB24WHATEVER.ZIP'). This could be also a problem with the client (I'm working with the developer in parallel to settle this). But I would like it, to have the original glitch out of the way.
(*) btw, https is not working with self-signed certificates as provided by "Let's encrypt"
-
dstillmanCan you provide a Debug ID for the first sync after adding a file locally? It's possible there's a regression here, though we haven't received any other reports of it. If you're using Let's Encrypt, it shouldn't be a self-signed certificate. For an actual self-signed certificate, you'd have to whitelist the certificate. If you're getting a certificate error for a genuine LE certificate, can you provide a Debug ID that shows that happening?