Error file syncing: Report ID 986837223

girones

After being let down by the guys of http://www.cloudsafe.com (who are closing down) I am attempting to set up a local WebDAV server on top of a TrueCrypt drive and use DropBox to synchronize amongst machines.

I think I managed to configure IIS 7.5 WebDAV on Windows 7: I am able to use BitKinex on a 'zotero' virtual directory, and the Zotero server verification button returns "File sync is successfully set up.".

However, when I try to synchronize my database a red question mark button appears reporting that web upload has failed after uploading a bunch of files. The report ID is 986837223 and the error code is HTTP 404.

In addition, the IIS log shows the following entries:

014-09-26 16:12:48 ::1 GET /zotero/ZKTSATMM.prop - 8080 webdav_zotero ::1 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:32.0)+Gecko/20100101+Firefox/32.0 404 0 2 0
2014-09-26 16:12:48 ::1 PUT /zotero/ZKTSATMM.zip - 8080 webdav_zotero ::1 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:32.0)+Gecko/20100101+Firefox/32.0 201 0 0 10
2014-09-26 16:12:48 ::1 PUT /zotero/ZKTSATMM.prop - 8080 webdav_zotero ::1 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:32.0)+Gecko/20100101+Firefox/32.0 201 0 0 10
2014-09-26 16:12:48 ::1 GET /zotero/ZRMBQU84.prop - 8080 webdav_zotero ::1 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:32.0)+Gecko/20100101+Firefox/32.0 404 0 2 0
2014-09-26 16:12:48 ::1 PUT /zotero/ZRMBQU84.zip - 8080 webdav_zotero ::1 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:32.0)+Gecko/20100101+Firefox/32.0 201 0 0 10
2014-09-26 16:12:49 ::1 PUT /zotero/ZRMBQU84.prop - 8080 webdav_zotero ::1 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:32.0)+Gecko/20100101+Firefox/32.0 201 0 0 0
2014-09-26 16:12:49 ::1 GET /zotero/ZSV5BF6J.prop - 8080 webdav_zotero ::1 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:32.0)+Gecko/20100101+Firefox/32.0 404 0 2 0
2014-09-26 16:12:49 ::1 PUT /zotero/ZSV5BF6J.zip - 8080 webdav_zotero ::1 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:32.0)+Gecko/20100101+Firefox/32.0 201 0 0 20
2014-09-26 16:12:49 ::1 PUT /zotero/ZSV5BF6J.prop - 8080 webdav_zotero ::1 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:32.0)+Gecko/20100101+Firefox/32.0 201 0 0 20
2014-09-26 16:12:50 ::1 GET /zotero/227VWFMM.prop - 8080 webdav_zotero ::1 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:32.0)+Gecko/20100101+Firefox/32.0 404 0 2 0
2014-09-26 16:12:50 ::1 PUT /zotero/227VWFMM.zip - 8080 webdav_zotero ::1 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:32.0)+Gecko/20100101+Firefox/32.0 201 0 0 30
2014-09-26 16:12:50 ::1 PUT /zotero/227VWFMM.prop - 8080 webdav_zotero ::1 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:32.0)+Gecko/20100101+Firefox/32.0 201 0 0 0
2014-09-26 16:12:50 ::1 GET /zotero/22R75MF9.prop - 8080 webdav_zotero ::1 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:32.0)+Gecko/20100101+Firefox/32.0 404 0 2 0
2014-09-26 16:12:50 ::1 PUT /zotero/22R75MF9.zip - 8080 webdav_zotero ::1 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:32.0)+Gecko/20100101+Firefox/32.0 201 0 0 20
2014-09-26 16:12:51 ::1 PUT /zotero/22R75MF9.prop - 8080 webdav_zotero ::1 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:32.0)+Gecko/20100101+Firefox/32.0 201 0 0 0
2014-09-26 16:12:51 ::1 GET /zotero/7HT9WRKB.prop - 8080 webdav_zotero ::1 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:32.0)+Gecko/20100101+Firefox/32.0 404 0 2 0
2014-09-26 16:12:51 ::1 GET /zotero/23JCPG5F.prop - 8080 webdav_zotero ::1 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:32.0)+Gecko/20100101+Firefox/32.0 404 0 2 0
2014-09-26 16:12:51 ::1 PUT /zotero/23JCPG5F.zip - 8080 webdav_zotero ::1 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:32.0)+Gecko/20100101+Firefox/32.0 201 0 0 10
2014-09-26 16:12:51 ::1 PUT /zotero/7HT9WRKB.zip - 8080 - ::1 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:32.0)+Gecko/20100101+Firefox/32.0 404 13 0 120
2014-09-26 16:12:51 ::1 PUT /zotero/23JCPG5F.prop - 8080 webdav_zotero ::1 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:32.0)+Gecko/20100101+Firefox/32.0 201 0 0 0

It seems that the culprit is

2014-09-26 16:12:51 ::1 PUT /zotero/7HT9WRKB.zip - 8080 - ::1 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+rv:32.0)+Gecko/20100101+Firefox/32.0 404 13 0 120

which returns a HTTP 404 file not found. The only difference I see with the other entries is that the webdav_zotero user that I created for WebDAV is not passed as a parameter.

This error occurs consistently and I do not know if this is a problem with my configuration or a bug in Zotero. Can someone provide advice?

Thanks,
Xavier

dstillman

I'd need a Debug ID (not Report ID) for a failed sync, but if you're using Dropbox to sync the 'storage' directory between machines, is it necessary to bother with WebDAV? Can you just link the 'storage' directory into the TrueCrypt volume directly? (I'm actually not sure if you can use a Windows alias in that manner, but someone else would know.)

girones

Hi Dan, thank you for your answer.

Here is the Debug ID: D1669359745.

I like the idea of keeping the local and the remote repository separated, and the remotes replicated. If I keep the local repository in a DropBox folder, any change I make in a local database will be automatically replicated to the other boxes. The problem is that if one of the local databases gets corrupted, DropBox will corrupt the other repositories.

I am using the same approach with Git. I commit to local Git repositories, and my remote is on a TrueCrypt drive synchronized with DropBox. It works great. By the way, I resorted to this solution after suffering the nightmare of losing my subversion repositories in Codespaces. The take away of the story is that the cloud is a very dangerous place to keep important data.

http://www.esecurityplanet.com/network-security/code-spaces-destroyed-by-cyber-attack.html

Please let me know if there is any additional test I should do.
Thanks!

aurimas

When you talk about keeping "repositories" in a DropBox folder and syncing it to other machines, what exactly are you referring to with "repositories"?

adamsmith

in particular in the context of Zotero. It's clear (at least to me) what you mean by git repositories.

girones

I am referring to the zotero database, the one that is revealed using the "Show Data Directory" button and usually kept under '...\Firefox\Profiles\...\zotero'.

Is there anyone synchronizing this folder directly with DropBox? Isn't it dangerous?

aurimas

Isn't it dangerous?

Yes, and highly discouraged. So much so that we will not provide support if you have your zotero.sqlite syncing between different computers via a third-party service. Dan above refers specifically to the "storage" directory that contains only file attachments and is safe to sync.

Edit: I should add that WebDAV would be equivalent to having your "storage" directory inside DropBox, which is why Dan said there's no point in having WebDAV and DropBox syncing simultaneously.

girones

Thanks. I did not know that syncing the "storage" directory was safe. It is a good workaround in case I cannot make the local WebDAV server work with Zotero. I still prefer the local WebDAV approach though.

girones

There is a difference: if I directly sync the "storage" directory with dropbox, any local changes will be automatically replicated to the other instances of Zotero, whereas using WebDAV any local changes will not be replicated unless I click on the "Sync with Zotero server" button.

aurimas

right, not the same, but mostly equivalent (I was actually thinking of pointing that out, but...)

aurimas

See http://forums.iis.net/t/1181476.aspx for the WebDAV issue. Might be the same

Edit: also http://www.webtrenches.com/post.cfm/iis7-file-upload-size-limits

Edit2: for future reference, I'm guessing that the IIS log is showing a 404.13 response code ("404 13 0 120"). Never seen response codes like that, but seems like it's a thing. Should probably be returning 413 instead.

girones

You are completely right, it should be a 413. I have checked my IIS configuration and the maximum request file size limit was set 30 Mb, and guess what? I was trying to upload a 31 Mb file :o)

This HTTP 404 was misleading. I have spend the entire day chasing a ghost "not found" problem. Anyway, my WebDAV + Truecrypt + Dropbox Frankenstein is up and running now, and I owe it to you.

Thank you very much!

aurimas

Dan, out of curiosity, what was the response and status code in the debug log (D1669359745) for that 404 response?

dstillman

Yes, the server was returning 404, not 413. The bizarro made-up MS error code in the error message was 404.13, with a message explaining the problem.

aurimas

I was just wondering if we can detect 404.13 and provide a better message to the user. Seems like the debug log would have contained the explanation anyway though.