WebDAV not syncing with FolderSync anymore with 6.0.3

Hello,

I am having problems with webDAV since having upgraded to 6.0.3. Im am using the webdav feature with nginx as a webserver. Prior to upgrading, I was perfectly happy with syncing my files from phone via foldersync.

Now FolderSync gives me an error:

file transfer failed: FILE
attempt to read from field java.lang.strict.dk.tacit.android.providers.file.providerfile.displaypath on a null object reference

From seavdav.error.log:

File "/home/seafile/seafile/seafile-server-6.0.3/seahub/thirdpart/wsgidav/request_server.py", line 902, in       _**copyOrMove**
srcRes, HTTP_NO_CONTENT, errorList)
File "/home/seafile/seafile/seafile-server-6.0.3/seahub/thirdpart/wsgidav/request_server.py", line 146, in  _sendResponse
return util.sendStatusResponse(environ, start_response, errorList[0][1])
File "/home/seafile/seafile/seafile-server-6.0.3/seahub/thirdpart/wsgidav/util.py", line 758, in sendStatusResponse
assert type(body) is str # If not, Content-Length is wrong!
AssertionError" while reading response header from upstream, client: 10.0.0.1, server: XXX.XXX.net, request:     "**MOVE** /seafdav/FOLDER/FOLDER/2
2016/09/17 20:16:19 [error] 9495#0: *178168 FastCGI sent in stderr: "" while reading response header from  upstream, client: 10.0.0.1, server: XXX.XXX.net, request: "**MOVE /seafdav/seafdav/FILE/XY**

Does anybody has similiar errors?
I can browse webdav via firefox without any problems. From the error itself it seems foldersync can’t move the file on webdav?

BR,
one

2 Likes

I have the same issue.

Same error also with other apps (Sold Explorer).

Yes, I’ve had this issue with both Keepass2Android and Keeweb when trying to sync my keepass database over Webdav. I had discussed it a little with @Jonathan , but the conversation lost momentum (my fault, I think I forgot to reply!).

I stopped my server, wiped out my logs, and restarted the server. I then opened a file over Webdav and tried to save it. This was the only output in the logs.

==> ccnet.log <==
[09/03/16 18:33:47] ../common/session.c(398): Accepted a local client
[09/03/16 18:33:47] ../common/session.c(398): Accepted a local client
[09/03/16 18:33:47] ../common/session.c(398): Accepted a local client
[09/03/16 18:33:50] ../common/session.c(398): Accepted a local client
[09/03/16 18:33:50] ../common/peer.c(943): Local peer down
[09/03/16 18:34:07] ../common/session.c(398): Accepted a local client
[09/03/16 18:34:11] ../common/session.c(398): Accepted a local client
[09/03/16 18:34:20] ../common/session.c(398): Accepted a local client
[09/03/16 18:34:52] ../common/session.c(398): Accepted a local client
[09/03/16 18:34:55] ../common/session.c(398): Accepted a local client

==> controller.log <==
[09/03/16 18:33:46] seafile-controller.c(154): starting ccnet-server ...
[09/03/16 18:33:46] seafile-controller.c(73): spawn_process: ccnet-server -F /srv/seafile/conf -c /srv/seafile/ccnet -f /srv/seafile/logs/ccnet.log -d -P /srv/seafile/pids/ccnet.pid
[09/03/16 18:33:46] seafile-controller.c(88): spawned ccnet-server, pid 8088
[09/03/16 18:33:47] seafile-controller.c(555): ccnet daemon connected.
[09/03/16 18:33:47] seafile-controller.c(186): starting seaf-server ...
[09/03/16 18:33:47] seafile-controller.c(73): spawn_process: seaf-server -F /srv/seafile/conf -c /srv/seafile/ccnet -d /srv/seafile/seafile-data -l /srv/seafile/logs/seafile.log -P /srv/seafile/pids/seaf-server.pid
[09/03/16 18:33:47] seafile-controller.c(88): spawned seaf-server, pid 8095
[09/03/16 18:33:47] seafile-controller.c(396): pid file /srv/seafile/pids/seafdav.pid does not exist
[09/03/16 18:33:47] seafile-controller.c(73): spawn_process: /usr/bin/python2.7 -m wsgidav.server.run_server runfcgi --log-file /srv/seafile/logs/seafdav.log --pid /srv/seafile/pids/seafdav.pid --port 8080 --host localhost
[09/03/16 18:33:47] seafile-controller.c(88): spawned /usr/bin/python2.7, pid 8096

==> seafdav.log <==
  File "/srv/seafile/seafile-server-6.0.3/seahub/thirdpart/wsgidav/request_server.py", line 756, in doMOVE
return self._copyOrMove(environ, start_response, True)
  File "/srv/seafile/seafile-server-6.0.3/seahub/thirdpart/wsgidav/request_server.py", line 902, in _copyOrMove
srcRes, HTTP_NO_CONTENT, errorList)
  File "/srv/seafile/seafile-server-6.0.3/seahub/thirdpart/wsgidav/request_server.py", line 146, in _sendResponse
return util.sendStatusResponse(environ, start_response, errorList[0][1])
  File "/srv/seafile/seafile-server-6.0.3/seahub/thirdpart/wsgidav/util.py", line 758, in sendStatusResponse
assert type(body) is str # If not, Content-Length is wrong!
AssertionError


==> seafile.log <==
[09/03/2016 06:33:48 PM] ../common/mq-mgr.c(54): [mq client] mq cilent is started
[09/03/2016 06:34:45 PM] ../common/seaf-db.c(859): Error prepare statement SELECT commit_id FROM Branch WHERE name=? AND repo_id=?: sqlite3_prepare_v2 failed: database is locked.

==> seahub_django_request.log <==
2016-09-04 06:34:52,143 [WARNING] django.request:170 get_response Not Found: /favicon.ico
2016-09-04 06:34:52,312 [WARNING] django.request:170 get_response Not Found: /favicon.ico

==> seahub.log <==
<empty>

hi, I confirm that I have the same error using seafile on ubuntu 16.04. I thought it was a permissions thing at first, but now I see that it’s a bigger issue. Does anyone know a workaround yet ? I’m using foldersync using webdav and I bought the paid version of that app specifically because I want to back up the data on my phone each night :frowning:

I notice there’s a bunch of files ending .tacitpart that get created when it tries to sync, does that give any clue?

For avoidance of doubt when I stopped Seafile Server 6.0.3 and restarted using Seafile Server 5.1.3, it syncs correctly.

It seems that some Webdav clients, including the ones I am using, first save a tmp file on the server, and then move or rename that to the real file name. It is this move/rename action that is failing.

So your files are probably backed up ok, but are just saved in the .tacitpart temp files for now.

1 Like

You can deactivate this behavior by disabling the Temp-file scheme within the FolderPair settings

1 Like

Great suggestion. But just keep in mind that this is a workaround and not a solution. The server-side issues need to be corrected.

good find! thank you, I’ll give it a try

It most likely is the move part. The files get uploaded properly (MD5 checksum OK), only the move part from file.tacitpart to file is failing:

File "/home/seafile/seafile/seafile-server-6.0.3/seahub/thirdpart/wsgidav/request_server.py", line 902, in      _**copyOrMove**
srcRes, HTTP_NO_CONTENT, errorList)
File "/home/seafile/seafile/seafile-server-6.0.3/seahub/thirdpart/wsgidav/request_server.py", line 146, in  _sendResponse
return util.sendStatusResponse(environ, start_response, errorList[0][1])
File "/home/seafile/seafile/seafile-server-6.0.3/seahub/thirdpart/wsgidav/util.py", line 758, in sendStatusResponse
assert type(body) is str # If not, Content-Length is wrong!
AssertionError" while reading response header from upstream, client: 10.0.0.1, server: XXX.XXX.net, request:   "**MOVE** /seafdav/Mobile_sync/expense/2
2016/09/17 20:16:19 [error] 9495#0: *178168 FastCGI sent in stderr: "" while reading response header from  upstream, client: 10.0.0.1, server: XXX.XXX.net, request: "**MOVE /seafdav/seafdav/FILE/XY**

That’s why Jacks workaround is working fine! Unticking the “temp” option in FolderSync makes uploading possible.
Where does Seafile tracks its’ bugs, GitHub?

yes, under github/haiwen

Opened an issue: https://github.com/haiwen/seafdav/issues/15

The cause has been found. We changed the internal file move api in 6.0. But we forgot to update webdav. It’ll be fixed in 6.0.4. Thanks for reporting.

1 Like

Thanks @Jonathan for clearing this up so fast.

This issue came up again on my end. See also:

You may try to upgrade to 7.1 version, which contains a major upgrade to the webdav functionality. That may solve the issue.

I’m already on 7.1.3, the problem persists.

Same here, it was fine on 7.0.X so it’s something bugged again in 7.1.X

Seems to be the same case for me