[Owncloud] Fwd: How I just lost 2/3 of my files to the sync-client

[Benjamin Schieder]

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 at 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 at 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: blindcoder at jabber.ccc.de
Twitter: blind_coder
Web: http://www.crash-override.net/