Re: [Owncloud] Fwd: How I just lost 2/3 of my files to the sync-client
WOOHOOO! Awesome news :-) Thanks for looking into this! As a developer myself, I know that my bug-report was less-than-ideal. All the more awesome that you found and fixed it, anyway! Kind regards, Benjamin Am 2014-02-06 19:05, schrieb Klaas Freitag: On 06.02.2014 10:23, Klaas Freitag wrote: Hi, good news here. As we are sitting together for a hackathon on the client this week, we were able to have a deeper look into this problem and our friend Olivier was actually able to nail the problem down and fix it. It indeed was a problem with the renaming mechanism, and both the problem and the solution are hard to understand ;-) But: The fix will arrive with the next client release (RC2 or final). Thanks Olivier for fixing and thanks for the report! regards, Klaas 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? ___ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud ___ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] Fwd: How I just lost 2/3 of my files to the sync-client
Great news! Is there a way to reproduce the problem with and without the fix? I think we could help you out in testing in our local environments / OSes if we knew how to reproduce it. kuba -- On Feb 6, 2014, at 7:05 PM, Klaas Freitag wrote: > On 06.02.2014 10:23, Klaas Freitag wrote: > > Hi, > > good news here. > > As we are sitting together for a hackathon on the client this week, we were > able to have a deeper look into this problem and our friend Olivier was > actually able to nail the problem down and fix it. > > It indeed was a problem with the renaming mechanism, and both the problem and > the solution are hard to understand ;-) > > But: The fix will arrive with the next client release (RC2 or final). > > Thanks Olivier for fixing and thanks for the report! > > regards, > > Klaas > >> 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? > > > ___ > Owncloud mailing list > [email protected] > https://mail.kde.org/mailman/listinfo/owncloud ___ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] Fwd: How I just lost 2/3 of my files to the sync-client
On Thu, Feb 6, 2014 at 10:05 PM, Klaas Freitag wrote: > On 06.02.2014 10:23, Klaas Freitag wrote: > > Hi, > > good news here. > > As we are sitting together for a hackathon on the client this week, we > were able to have a deeper look into this problem and our friend Olivier > was actually able to nail the problem down and fix it. > > It indeed was a problem with the renaming mechanism, and both the problem > and the solution are hard to understand ;-) > > But: The fix will arrive with the next client release (RC2 or final). > > Thanks Olivier for fixing and thanks for the report! > Great news! The simple "trash" feature on client side can also minimize risk of losing data with such bugs. There are bug reports available for this feature request. Just move the files deleted on the server to a trash directory. ___ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] Fwd: How I just lost 2/3 of my files to the sync-client
On 06.02.2014 19:25, Emre Erenoglu wrote: On Thu, Feb 6, 2014 at 10:05 PM, Klaas Freitag wrote: On 06.02.2014 10:23, Klaas Freitag wrote: Hi, good news here. As we are sitting together for a hackathon on the client this week, we were able to have a deeper look into this problem and our friend Olivier was actually able to nail the problem down and fix it. It indeed was a problem with the renaming mechanism, and both the problem and the solution are hard to understand ;-) But: The fix will arrive with the next client release (RC2 or final). Thanks Olivier for fixing and thanks for the report! Great news! The simple "trash" feature on client side can also minimize risk of losing data with such bugs. There are bug reports available for this feature request. Just move the files deleted on the server to a trash directory. I agree. Klaas ___ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] Fwd: How I just lost 2/3 of my files to the sync-client
On 06.02.2014 10:23, Klaas Freitag wrote: Hi, good news here. As we are sitting together for a hackathon on the client this week, we were able to have a deeper look into this problem and our friend Olivier was actually able to nail the problem down and fix it. It indeed was a problem with the renaming mechanism, and both the problem and the solution are hard to understand ;-) But: The fix will arrive with the next client release (RC2 or final). Thanks Olivier for fixing and thanks for the report! regards, Klaas 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? ___ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] Fwd: How I just lost 2/3 of my files to the sync-client
Am 2014-02-06 14:28, schrieb Klaas Freitag: On 05.02.2014 14:20, Benjamin Schieder wrote: At some point, the sync client encountered a 500 Internal server error and stopped working. During investigation, the sync client crashed and I restarted it. Can you maybe remember when that hapened? What did you do to "investigate"? We analyzed on here, but still can not reconstruct a situation that lead to the described behaviour. Maybe you remember more information? After the 500, I opened the clients "Activity" tab. I _think_ it crashed when I clicked "retry sync". Now it started to sync again but started deleting files on the server and locally. Ok, here is why files are deleted: a) on the client: The files are listed in the client journal and have not changed (compared to the database entries). Now on the sync run the server has the files not longer in the listing. That means they have been removed on server side and that is done than on client side as well. b) on the server: very similar, the files are in the client database but not longer present in the physical local file system. That means they were locally deleted. If they are still in the same state as before on the server, the local remove is propagated and the files are deleted on the server. In the end, only the files successfully "Moved" were kept, all others that existed on the server but not on the client or vice-versa were deleted. Benjamin, can you provide the server access log of that accident? I will prepare it. ___ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] Fwd: How I just lost 2/3 of my files to the sync-client
a) on the client: The files are listed in the client journal and have not changed (compared to the database entries). Now on the sync run the server has the files not longer in the listing. If the file is locally unchanged, then why would the client even try to sync the file again? Is it because it is re-trying the operation causing an error before (i.e. the rename in this case)? If so, then wouldn't a fix for this be as "simple" as checking for such a failed operation, before retrying it, whether it has already been done successfully in the meantime? Regards, Randolph On 06.02.2014 14:28, Klaas Freitag wrote: On 05.02.2014 14:20, Benjamin Schieder wrote: At some point, the sync client encountered a 500 Internal server error and stopped working. During investigation, the sync client crashed and I restarted it. Can you maybe remember when that hapened? What did you do to "investigate"? We analyzed on here, but still can not reconstruct a situation that lead to the described behaviour. Maybe you remember more information? Now it started to sync again but started deleting files on the server and locally. Ok, here is why files are deleted: a) on the client: The files are listed in the client journal and have not changed (compared to the database entries). Now on the sync run the server has the files not longer in the listing. That means they have been removed on server side and that is done than on client side as well. b) on the server: very similar, the files are in the client database but not longer present in the physical local file system. That means they were locally deleted. If they are still in the same state as before on the server, the local remove is propagated and the files are deleted on the server. In the end, only the files successfully "Moved" were kept, all others that existed on the server but not on the client or vice-versa were deleted. Benjamin, can you provide the server access log of that accident? Thx, Klaas ___ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud ___ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] Fwd: How I just lost 2/3 of my files to the sync-client
On 05.02.2014 14:20, Benjamin Schieder wrote: At some point, the sync client encountered a 500 Internal server error and stopped working. During investigation, the sync client crashed and I restarted it. Can you maybe remember when that hapened? What did you do to "investigate"? We analyzed on here, but still can not reconstruct a situation that lead to the described behaviour. Maybe you remember more information? Now it started to sync again but started deleting files on the server and locally. Ok, here is why files are deleted: a) on the client: The files are listed in the client journal and have not changed (compared to the database entries). Now on the sync run the server has the files not longer in the listing. That means they have been removed on server side and that is done than on client side as well. b) on the server: very similar, the files are in the client database but not longer present in the physical local file system. That means they were locally deleted. If they are still in the same state as before on the server, the local remove is propagated and the files are deleted on the server. In the end, only the files successfully "Moved" were kept, all others that existed on the server but not on the client or vice-versa were deleted. Benjamin, can you provide the server access log of that accident? Thx, Klaas ___ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] Fwd: How I just lost 2/3 of my files to the sync-client
Am 2014-02-06 10:53, schrieb Christian Weiske: Hello Klaas, >>> [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] > He is using FCGI (FastCGI), which starts separate PHP processes and > waits for a couple of seconds. If the PHP process doesn't respond > within that time, cgi will see it as "fail" and send a 500 back to > the client. > > The PHP process will still run on. Ok, in that cas e there is no chance at all to handle that correctly. Oh, there is. The server app could send a dot or whatever every couple of seconds, so that there is something to send to the client and the cgi process sees that the php process did not crash. Or finish early with a "processing" state, put it in a queue and let the client pull every couple of seconds to see if it's done. I'm not sure if the WebDAV protocol supports these ideas. I've only been developing CardDAV stuff, which is based on WebDAV, but so far I haven't seen a way for "asynchronous" processing. Also, you can't send "dots" because you have to send the HTTP status first, which can only be determined at the end of the operation. -- Jabber: [email protected] Twitter: blind_coder Web: http://www.crash-override.net/ ___ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] Fwd: How I just lost 2/3 of my files to the sync-client
Le 06/02/2014 10:53, Christian Weiske a écrit : Hello Klaas, [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] He is using FCGI (FastCGI), which starts separate PHP processes and waits for a couple of seconds. If the PHP process doesn't respond within that time, cgi will see it as "fail" and send a 500 back to the client. The PHP process will still run on. Ok, in that cas e there is no chance at all to handle that correctly. Oh, there is. The server app could send a dot or whatever every couple of seconds, so that there is something to send to the client and the cgi process sees that the php process did not crash. Or finish early with a "processing" state, put it in a queue and let the client pull every couple of seconds to see if it's done. Hello, That would be great and necessary because nowadays, FastCGI/PHP-FPM mechanisms are largely used to perform better. ___ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud ___ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] Fwd: How I just lost 2/3 of my files to the sync-client
Hello Klaas, > >>> [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] > > He is using FCGI (FastCGI), which starts separate PHP processes and > > waits for a couple of seconds. If the PHP process doesn't respond > > within that time, cgi will see it as "fail" and send a 500 back to > > the client. > > > > The PHP process will still run on. > Ok, in that cas e there is no chance at all to handle that correctly. Oh, there is. The server app could send a dot or whatever every couple of seconds, so that there is something to send to the client and the cgi process sees that the php process did not crash. Or finish early with a "processing" state, put it in a queue and let the client pull every couple of seconds to see if it's done. -- Regards/Mit freundlichen Grüßen Christian Weiske -=≡ Geeking around in the name of science since 1982 ≡=- signature.asc Description: PGP signature ___ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] Fwd: How I just lost 2/3 of my files to the sync-client
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
Re: [Owncloud] Fwd: How I just lost 2/3 of my files to the sync-client
On 06.02.2014 10:28, Christian Weiske wrote: Hi, [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 operation probably did finish server-side. He is using FCGI (FastCGI), which starts separate PHP processes and waits for a couple of seconds. If the PHP process doesn't respond within that time, cgi will see it as "fail" and send a 500 back to the client. The PHP process will still run on. Ok, in that cas e there is no chance at all to handle that correctly. Klaas You can configure your web server's CGI to wait longer, but that's a bit tricky[1]. [1] http://cweiske.de/tagebuch/Running%20Apache%20with%20a%20dozen%20PHP%20versions.htm#timeout ___ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] Fwd: How I just lost 2/3 of my files to the sync-client
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
Re: [Owncloud] Fwd: How I just lost 2/3 of my files to the sync-client
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). 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--). 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? 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
Re: [Owncloud] Fwd: How I just lost 2/3 of my files to the sync-client
Hello Klaas, >> [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 operation probably did finish server-side. He is using FCGI (FastCGI), which starts separate PHP processes and waits for a couple of seconds. If the PHP process doesn't respond within that time, cgi will see it as "fail" and send a 500 back to the client. The PHP process will still run on. You can configure your web server's CGI to wait longer, but that's a bit tricky[1]. [1] http://cweiske.de/tagebuch/Running%20Apache%20with%20a%20dozen%20PHP%20versions.htm#timeout -- Regards/Mit freundlichen Grüßen Christian Weiske -= Geeking around in the name of science since 1982 =- ___ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] Fwd: How I just lost 2/3 of my files to the sync-client
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 [email protected] https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] Fwd: How I just lost 2/3 of my files to the sync-client
Benjamin Schieder wrote: > I was able to restore the files from another machines sync directory, > but it was very scary nonetheless. Thank you for the warning, Benjamin. Reading the sentence I quoted above, it now seems obvious (although I had never thought to do this before) that when upgrading the sync client or the Owncloud server -- or making any large change to the synced directories -- it is probably a really good idea to temporarily disable syncing to one client in order to protect its synced directory from being corrupted if anything goes wrong. I mean... I have server snapshots taken every four hours, and my clients are backed up regularly, but the backup files are (intentionally) not easy to access, and they can of course be up to four hours old. And besides, a backup that occurs halfway through a sync or while a file is open might not be perfect anyway. For these reasons, I have in the past made a temporary copy of one client's synced directory just before upgrading the client or server. But lately, my synced directory is so large that finding disk space (and time) for a copy is difficult. Disabling the sync client on a machine that is already synced takes no time and no extra disk space, and it preserves an up-to-the-minute, internally consistent backup that can be easily copied back to the server if necessary. I haven't looked at the Owncloud documentation lately, but I assume that it says (maybe in multiple places) something like "It is recommended to have a recent backup whenever making a large change to your system". Perhaps it would be helpful to also suggest temporarily disabling one sync client. -Andrew === Andrew Warren - [email protected] === Synaptics, Inc - Santa Clara, CA ___ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] Fwd: How I just lost 2/3 of my files to the sync-client
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 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. The sync client then started working on that and the logfile showed lots of "Moved" messages. All fine so far. Which logfile? Was it the apache log or the client log? In the "Details" section of the client UI. 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 During investigation, the sync client crashed and I restarted it. Now it started to sync again but started deleting files on the server and locally. In the end, only the files successfully "Moved" were kept, all others that existed on the server but not on the client or vice-versa were deleted. That is strange, and we do not have an explanation to that. Maybe you have more input on our questions. Personally, I'd call that a serious bug but am unsure how I can and if I want to reproduce it. I was able to restore the files from another machines sync directory, but it was very scary nonetheless. Yes, sorry for that. No problem. As I had the data on two more devices, there was nothing lost. Personally, I think that the size of the Work directory, the timeout of PHP and the subsequest crash of the sync client left some databases in strange states resulting in this. Kind regards, Benjamin ___ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
Re: [Owncloud] Fwd: How I just lost 2/3 of my files to the sync-client
On 05.02.2014 14:20, Benjamin Schieder wrote: Hello there. The subject is intentionally scary but it's equally important, at least I think so. I just lost about 2/3 of my files to the sync client version 1.5.0 running on Debian connected to an owncloud instance version 5.0.13 also running on Debian. I'm writing this here down to warn others of this particular caveat. I have a fairly big owncloud files directory. Around 20 GB spread over thousands of files. I used to have a clientsync/ directory that was synced between three computers. 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? Well, that was fine with me, so I decided to move the directories from /clientsync/* to / . Where? On the server or on the client? The sync client then started working on that and the logfile showed lots of "Moved" messages. All fine so far. Which logfile? Was it the apache log or the client log? 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? During investigation, the sync client crashed and I restarted it. Now it started to sync again but started deleting files on the server and locally. In the end, only the files successfully "Moved" were kept, all others that existed on the server but not on the client or vice-versa were deleted. That is strange, and we do not have an explanation to that. Maybe you have more input on our questions. Personally, I'd call that a serious bug but am unsure how I can and if I want to reproduce it. I was able to restore the files from another machines sync directory, but it was very scary nonetheless. Yes, sorry for that. Klaas ___ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
