Am 2014-02-06 10:40, schrieb Klaas Freitag:
On 06.02.2014 10:35, Benjamin Schieder wrote:
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'm running a script session for it and will send you the link to it
later in a private mail.
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.
Ah, that works, thanks. I assumed that sqlite was identical to the
sqlite3 binary.
Kind regards,
Benjamin
--
Jabber: [email protected]
Twitter: blind_coder
Web: http://www.crash-override.net/
_______________________________________________
Owncloud mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/owncloud
