On 06.02.2014 10:35, Benjamin Schieder wrote:
Am 2014-02-06 10:23, schrieb Klaas Freitag:
On 05.02.2014 15:38, Benjamin Schieder wrote:
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.
That makes sense, obviously.
I wonder why there was a timeout in the first place. A filesystem move
operation takes milliseconds, no matter the size of the directory
(unless you cross filesystem boundaries, of course).
I am not sure how the move is implemented on the server. There might be
restriction because of all the different backends.
At least some kind of explanation. Yet I am not sure how we can handle
it on the client except not really doing deletes.
Right now I don't have an idea either.
But I just noticed something strange: The sync client keeps syncing
files that are in sync already. I confirmed this by running unison to
check for differences and the only diffs are file modes (-rwxrwx--- vs.
-rw-rw-r--).
Can you try to catch a log from that?
I tried looking into the .csync_journal.db but sqlite says:
[10:34:13][blindcoder@flora:~]$ sqlite ownCloud/.csync_journal.db
Unable to open database "ownCloud/.csync_journal.db": file is encrypted
or is not a database
[10:34:21][ret:1][blindcoder@flora:~]$ file ownCloud/.csync_journal.db
ownCloud/.csync_journal.db: SQLite 3.x database
Can it be that the db file got corrupted?
I don't think so, I rather think you should try sqlite_3_ . The sqlite
clients are not backward compatible unfortunately.
Klaas
_______________________________________________
Owncloud mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/owncloud
