On 05.02.2014 15:38, Benjamin Schieder wrote:
Am 2014-02-05 15:10, schrieb Klaas Freitag:
On 05.02.2014 14:20, Benjamin Schieder wrote:
After a reinstallation of my laptop and re-configuration of the sync
client, the client now synced the / directory of my server instead of
the /clientsync directory.
Did you have a previously configured client? Have you been asked if
you want to start over with a clean sync or keep the local files?
I had a previously configured client. For reasons I can't quite
reconstruct now, I removed the existing sync entry from the client and
added a new one. The new one didn't ask for a path and took the entire /
from the server.
Note that this sync worked like a charm!
After this initial sync I had the entire / from the server on my client
and everything where it bel
Ok, but this means that we do not deal with an update problem from one
client version to another, because it was a completely new set up client.
Well, that was fine with me, so I decided to move the directories from
/clientsync/* to / .
Where? On the server or on the client?
On the client.
Ok, so the client propagated the move to the server which we see in the
log snippet as well.
At some point, the sync client encountered a 500 Internal server error
and stopped working.
Why did that happen? Did you find something in the apache error log?
I'm not sure _why_. I guess that it's because the "Work" directory is
pretty big. The line from the access.log is:
x.x.x.x - - [31/Jan/2014:11:01:26 +0100] "MOVE
/remote.php/webdav/clientsync/Work HTTP/1.1" 500 906 "-" "Mozilla/5.0
(Linux) csyncoC/0.91.4 neon/0.30.0"
There's nothing in the error.log at the time, but a few entries like
this around it:
[Fri Jan 31 11:02:06 2014] [warn] [client 91.66.218.142] mod_fcgid: read
data timeout in 40 seconds
[Fri Jan 31 11:02:06 2014] [error] [client 91.66.218.142] Premature end
of script headers: remote.php
hmm, ok, so that looks like the server did not successfully finish the
MOVE operation but ran in a timeout. The question is now what the state
of the file system and database was on server side. On the client, we
handle the 500 error the way that it is assumed that the move did not
happen.
At least some kind of explanation. Yet I am not sure how we can handle
it on the client except not really doing deletes.
Klaas
_______________________________________________
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud
