Debug ID: D1653166455

I'm using 3.0b2.1 standalone.

Thanks!

It's definitely a problem with your WebDAV server—it's returning a 204 success code when Zotero uploads a file and then returning a 404 when Zotero requests that same file immediately afterward—but I made a small tweak to Zotero's upload code (saving a file with "1" as its contents instead of " ") on the off-chance that it works around the problem. The change will be available in the next 3.0 release, or you can try the trunk dev XPI of Zotero for Firefox pointed to your Standalone data directory (with Standalone closed). The trunk XPI should be fairly stable right now since it's about to be released as the next beta, but make a backup of your data directory for good measure and switch back to 3.0b2(.1) afterward.

But it's a bug in your WebDAV server, so if you're not comfortable doing the above then you should just talk to them.

I'm getting the same error through Box.net. It's strange because it has been working perfectly for the past couple of years and I have a ton of pdfs and such stored on there through zotero. Now I can't access them any more, and I don't understand why. I was wondering if it might be a linux issue, since I recently switched to Fedora 15 from Windows 7, but you all say it's a server issue. Did Box.net and this SMEStorage.com servers suddenly change something at the same time to generate this error? Very strange to me....

brushington: I've already reviewed the debug output for a box.net user. The server behavior is broken. This is not a bug in Zotero.

We might be able to make future versions of Zotero work around this, but making Zotero work with broken WebDAV servers is really not a priority. We provide Zotero File Storage for users who don't have access to a properly functioning WebDAV server (or who want the extra functionality Zotero File Storage offers).

2.1 uses a slightly different WebDAV sync method from 2.0 that actually makes it more compatible with (broken) WebDAV servers and restricted networks, but a badly behaving server might prefer one method over the other. On properly functioning servers they'll work identically.

For the record, here's an excerpt from ssauerw's output above:

(3)(+0000000): HTTP PUT ' ' to https://webdav.smestorage.com/zotero/zotero-test-file

(3)(+0001843): 

(3)(+0000000): ===>204<===(number)

(3)(+0000000): HTTP GET https://webdav.smestorage.com/zotero/zotero-test-file

(3)(+0001029): 

(3)(+0000000): ===>404<===(number)</pre>
A WebDAV server should never return a 404 for a file immediately after it was created (indicated by the 204). But these providers aren't in the business of providing WebDAV service, so it's not really that surprising that their implementations aren't entirely correct.

Possible workaround: The problem might just be that there's a delay before uploaded files are available, which would be a problem for the server verification but possibly not for a normal Zotero file sync. You can try going to about:config in the Firefox address bar (or clicking "Open about:config" from the Advanced pane of the preferences in Standalone) and setting extensions.zotero.sync.storage.verified to true, which will override the server verification and let you try to sync. No guarantees, obviously.

Yes, this workaround fixes the problem with box.net. Thank you!

Worked for me too, though "verify server" still returns the same error - as long as I can get my files, it's not an issue. :)

The workaround also worked for me. Box.net

I've created an issue for this.

Note that even with the workaround the verify server button will not work, but the files should be synching.

Since there's a chance this will occur with any cloud storage service backed by Amazon S3, in Zotero 3.0.13, now available, the server will pass verification—with a warning message—if the uploaded test file doesn't exist immediately after uploading, allowing you to attempt to sync.