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

[Klaas Freitag]

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