Upgrade Storagesyncing files does not work (Debug ID D1715543768)
Hi!
I tried to sync all my attached files with my webdav server (apache with mod_webdav (Apache/2.2.8 (Ubuntu) DAV/2)) but it does not work. The first sync works fine but newly created attachments do not show up on another computer. I followed all the steps on
http://www.zotero.org/support/kb/files_not_syncing
but still it does not work. Thus I created a debug id and send it to you. The file definitely exists on the webdav server...
TIA!
Thorsten
I tried to sync all my attached files with my webdav server (apache with mod_webdav (Apache/2.2.8 (Ubuntu) DAV/2)) but it does not work. The first sync works fine but newly created attachments do not show up on another computer. I followed all the steps on
http://www.zotero.org/support/kb/files_not_syncing
but still it does not work. Thus I created a debug id and send it to you. The file definitely exists on the webdav server...
TIA!
Thorsten
This discussion has been closed.
The skipped uploads are probably a result from the reset of sync history. The attachment was _not_ downloaded successfully, but I will try again in a minute....
1. Added a library item with pdf attachment on my work computer (Win XP). The upload took forever ("waiting for sync server"), but finally the upload finished (I had to restart firefox for this to work). The file is definitely on the webdav server:
http://billroth.ath.cx:8888/tmp/01.png
2. At home on my Mac I hit the sync button. As expected the library item appeared in the library but I was not able to download the attached pdf ("Attached file could not be found..."):
http://billroth.ath.cx:8888/tmp/02.png
3. I did the same with debug log enabled (D132013932). No success.
4. Then I did a reset of the sync history (D807527617). Again "waiting for the sync server" took forever but it finally finished. After that the attachment was there.
Thx for your efford! Please tell me if I can send you any further details!
Regards,
Thorsten
D1610967115
http://billroth.ath.cx:8888/tmp/03.png
It's sorted by date/time.
But I don't think that this is a webdav server problem. It's an up-to-date installation of mod_webdav on apache 2.2. If zotero correctly wrote the file each time the time/date stamp of the file would be correct... When I open a text file on the webdave share, change it on my deskop machine and save it again, the time/date stamp is updated correctly. Maybe you should save the last-sync-information within the file?
I tried an upload again. This time I had an "Error processing uploaded data (Report ID 61071927)". Bugreport 1576664224. I had debug log enabled: D507521579.
THX again!
D1293891148
You should be able to test this with your server with curl, at any rate.
THX!
Client:
apfel:~ ts$ echo "abc" > test
apfel:~ ts$ touch test
apfel:~ ts$ ls -l test
-rw-r--r-- 1 ts staff 4 23 Jul 15:54 test
apfel:~ ts$ curl -T test -u zotero:secret http://abc.de/zotero/test
(...waiting for 2 minutes...)
apfel:~ ts$ touch test
apfel:~ ts$ ls -l test
-rw-r--r-- 1 ts staff 4 23 Jul 15:56 test
apfel:~ ts$ curl -T test -u zotero:secret http://abc.de/zotero/test
Server:
root@abc:/etc/apache2# ls -l /var/zotero/test
-rw-r--r-- 1 www-data www-data 4 2010-07-23 15:54 test
root@abc:/etc/apache2# ls -l /var/zotero/test
-rw-r--r-- 1 www-data www-data 4 2010-07-23 15:56 test
However, it does _not_ work if the file is empty:
Client:
apfel:~ ts$ touch empty
apfel:~ ts$ ls -l empty
-rw-r--r-- 1 ts staff 0 23 Jul 16:03 empty
apfel:~ ts$ curl -T empty -u zotero:secret http://abc.de/zotero/empty
(...waiting for 2 minutes...)
apfel:~ ts$ touch empty
apfel:~ ts$ ls -l empty
-rw-r--r-- 1 ts staff 0 23 Jul 16:05 empty
apfel:~ ts$ curl -T empty -u zotero:secret http://abc.de/zotero/empty
Server:
root@abc:/etc/apache2# ls -l /var/zotero/empty
-rw-r--r-- 1 www-data www-data 0 2010-07-23 16:01 /var/zotero/empty
root@abc:/etc/apache2# ls -l /var/zotero/empty
-rw-r--r-- 1 www-data www-data 0 2010-07-23 16:01 /var/zotero/empty
My question is: is it possible to make "lastsync" not an empty file?
THX again!
Thorsten
Empty file:
apfel:~ ts$ curl -T empty -u zotero:secret --verbose http://abc.d/zotero/empty
* About to connect() to abc.de port 80 (#0)
* Trying 12.34.56.78... connected
* Connected to abc.de (12.34.56.78) port 80 (#0)
* Server auth using Basic with user 'zotero'
> PUT /zotero/empty HTTP/1.1
> Authorization: Basic xyz==
> User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7
OpenSSL/0.9.8l zlib/1.2.3
> Host: abc.de
> Accept: */*
> Content-Length: 0
> Expect: 100-continue
>
< HTTP/1.1 204 No Content
< Date: Fri, 23 Jul 2010 17:14:29 GMT
< Server: Apache/2.2.8 (Ubuntu) DAV/2 mod_python/3.3.1 Python/2.5.2 PHP/5.2.4-2ubuntu5.10 with Suhosin-Patch mod_ssl/2.2.8 OpenSSL/0.9.8g
< Content-Length: 0
< Content-Type: text/plain
<
* Connection #0 to host billroth.de left intact
* Closing connection #0
With a singe space in it:
apfel:~ ts$ curl -T empty -u zotero:secret --verbose http://abc.de/zotero/empty
* About to connect() to abc.de port 80 (#0)
* Trying 12.34.56.78... connected
* Connected to abc.de (12.34.56.78) port 80 (#0)
* Server auth using Basic with user 'zotero'
> PUT /zotero/empty HTTP/1.1
> Authorization: Basic xyz==
> User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3
> Host: abc.de
> Accept: */*
> Content-Length: 2
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
< HTTP/1.1 204 No Content
< Date: Fri, 23 Jul 2010 17:42:25 GMT
< Server: Apache/2.2.8 (Ubuntu) DAV/2 mod_python/3.3.1 Python/2.5.2 PHP/5.2.4-2ubuntu5.10 with Suhosin-Patch mod_ssl/2.2.8 OpenSSL/0.9.8g
< Content-Length: 0
< Content-Type: text/plain
<
* Connection #0 to host billroth.de left intact
* Closing connection #0
The only difference is the "< HTTP/1.1 100 Continue".
Regards,
Thorsten
Try the latest 2.0 branch XPI (not the trunk), which stores a space in the lastsync file.
In summery the reason for the trouble was that Apache/WebDAV did not update the timestamp of the file "lastsync" as long as this file was empty. If it is not empty the server seems to update the timestamp correctly.
Just out of curiosity I still would like to know what exactly the problem was and whether or not it is a bug or a feature of Apache/WebDAV. But I first have to read (and understand) RFC2616 (HTTP)....
Regards,
Thorsten
Note, though, that a 204 isn't a "rejection" (as the person in your httpd-apache thread suggested)—it's a success code. So if the server is returning a success code, I would argue that the timestamp should be updated—and your server does exactly that for non-empty files, which suggests that this is simply a bug. Bear in mind that Apache 2.2.8 was released in January 2008, so it's quite possible this isn't current behavior (and given that we've never seen it, I'm guessing it isn't).
Also, since there seems to be some confusion in your other thread, this has nothing to do with curl. I suggested using curl simply because it's the best way to test HTTP interactions.
---------- snip ----------
My interpretation of this is that
1) the server cannot be trusted to update properties such as time stamps
when modifying the content of a resource. I might be a very good idea,
but not a requirement.
2) A put of a zero size file to an existing zero size file might not be
considered a change int the body of the resource by all servers.
The proper (untested by me) way to do this in DAV probably is to use the
PROPPATCH method to set the time stamps (creationdate and
getlastmodified properties), and use PROPFIND to check them.
Using PROPPATCH would be the equivalent of using the "touch" command
line utility. If it works.
> apfel:~ ts$ curl -T empty -u zotero:secret --verbose
[output snipped]
Assuming that <http://abc.d/zotero/empty>; allready existed as that
command was executed I see nothing wrong in either the request or the
answer in that transaction.
I can't know wether the Date header in the answer is correct or not, but
note how RFC2616 uses MAY and SHOULD with relation to the 204 answer.
This means that the client can't really trust that the Date header in
the answer contains the new time stamp of the uploaded file.
---------- snip ----------
The whole thread can be found here:
http://thread.gmane.org/gmane.comp.apache.user/92345
Regards,
Thorsten
For what it's worth, I couldn't reproduce your empty-file behavior on Apache versions older (2.2.3) or newer (2.2.14) than yours, and we've never seen it with any other servers. There's not much point in diving into RFCs and debating the validity of what's clearly a fluke of upload processing (rather than an intentional design choice) of one particular version/build/configuration.
In any case, a whole lot of people's time has now been taken up by an issue that only one person experienced and that I fixed in five seconds, so I'm closing this thread. Glad to hear it's now working for you.