oC 1.2.0 Csync processing step propagate failed.

[covidium]

Backend message: Could not read response body, connection was closed by server.
This is the message that i get after i upgrade from 1.1.4 to 1.2.0 on openSUSE 12.2 x64, the server is 4.5.6 (4.90.7) and this is the error log that i get from the client https://mega.co.nz/#!R4R0ACYQ!YsyCD0XvVJ5afzACHukqthaWe-QwKUm0TcpfqnlqBZ0
Thanks

[Dusa]

I also get this message after updating the client from 1.1.4 to 1.2.0.
I use Windows 7 (64bit) as operating system, and the server version is 4.5.6

[woutervanrooy]

I am also facing this issue after upgrading to the 1.2.0 client today. Reverting to client 1.1.4 resolves the issue.
The server runs ownCloud v4.5.6 on Debian Squeeze; the offending workstation runs Mac OS X 10.8.2.

[dragotin]

@covidium: I can not access the logfile because I found no browser with a recent enough flash player. Can you find another place to put it ? Thanks.

[covidium]

@dragotin here is the file hosted @ 4shared. Thank you
http://www.4shared.com/office/3d-Ghtxa/oC_120_propagation_failed.html

[masakik]

Hi, I´m using 1.2.0 client on Windows 7 64bits and server 4.5.6 on linux and this issue started at second sincronization job to the "Shared" folder of the server. At server there are files that were shared read only from another user. When it starts syncing some files are copied and then the error is presented. After some more syncing all the files arrived and the error stopped, maybe until some file change.

[runekaa]

This is also an issue with server version 4.5.6 on centos and win7 client version 1.2.0

[covidium]

So nobody know what's the problem? @dragotin did you abbandon the help? I'm getting tired to test software, why the final release must be an release candidate ? why? with all the final releases i get to know the "big" bugs, when I upgraded the server some months ago my whole data was wiped out (luckly i had a backup) with, the client 1.1.4 sync stopped for a misterious cause (removing the csync_journal.db worked) now after the upgrade 1.2.0 stopped and for 9 days my whole sync is stopped because nobody know what's the problem. I understand that the opensource community in a way must test the software, but not this way. This is an unfriendly way. Everytime that i get news from owncloud i'm getting happy because i realy like this software but in the next second i'm chill remember that latest releases are in beta alpha or rc. So I think i'm moving the sync to another software if nobody answer in the next couple of days.

[runekaa]

I very much agree with you covidium. There are also major bugs which are carried on from old releases. I really like the idea behind this software, but it is far away from being feasible for production environments (and it is even sold as an enterprise version). This software would have been excellent if the development had been done in the correct way.

[dragotin]

@covidium I still can not download your logfile. It requires an account which I don't have.

@runekaa you should stay with the topic. Your last sentence is annoying and wrong.

You guys can help to improve the software, you were on a good way. You should think about what motivates others to fix bugs.

[danimo]

@dragotin the file in #272 (comment) seems to open here, the web interface is a bit annoying and confusing though.

@covidium: From the log you can see that the server delivers something that is not WebDAV XML, but also not an error. I suspect a web server configuration problem or a bug in the server, related gzip encoding. Can you move away all files ending in .gz or .tgz and try again?

Btw: The log was posted 5 days ago, 2 of them being a weekend, and we have been triaging a lot of issues. Sometimes we can reply almost instantly, sometimes it takes a while until we find time to analyse community reports.

[covidium]

@dragotin https://www.dropbox.com/s/5x7a16o7ajf4z2o/oC_1.2.0_propagation_failed.txt http://dl.transfer.ro/transfer_ro-04feb-fc866f53d1432774.zip I hope this time will work.

[covidium]

@danimo I understand that you are busy but a quick reply friendly reply is easy to post. :) however today i moved the sync folder from one of my computers and download the whole data from the server, as the client was downloading the archives i noticed that the error appeared again so i suspected that the issue was from that files. I deleted all compressed files but with no luck the error was once again back in the client.

[mihl]

I'm having the same issue. Any timeframe for a solution?

[masakik]

Hi, paying more attention to sync process seems that could be related to the webdav server. Seems that, as my apache run on about 50% of cpu, sometimes it is slow to respond to mirall than it crashes. But it continues on next sync and so on until complete all files. If there are a few small files every thing comes ok.

[shaneneuerburg]

I've noticed the same issue with large files as well.

[danimo]

Can you provide numbers on how big "big" really is?

[covidium]

@dragotin @danimo did you find something? did you need the servers log or something?

[shaneneuerburg]

@danimo I'm working with MP4 videos from 2-5GB in size. Let me know if there is anything I can do to help troubleshoot this.

[danimo]

@shaneneuerburg: We think we have fixed all obvious problems with files > 2GB, however there might be problems on the server side when the server is only 32 bit, since PHP's int overflows. Can you provide a logfile (run owncloud with the --logwindow parameter)?

[shaneneuerburg]

@danimo This is the entire log from start to the point where the error has occurred at least once: http://pastebin.com/iQ0A8kTV

[covidium]

18 days ago I was trying to get help from the oC dev's , my sync stopped after i upgraded to 1.2.0. As today I still can't sync my work folder , my picture folder and other folders that i had in the oC. This week when I was working on a project i needed some piece of code from a program that i made last year and the big surprise was that my source code was not complete, somehow last time when i had the issue with 1.1.4 client something happened and the sync went wrong, but not wrong with all the files only with some of them, comparing the two files (the one before and the one after the issue with 1.1.4) i noticed that the files are different:
The one after the accident
-rw-r--r-- 1 ovidiu users 0 Jan 18 19:53 script_nou_julia.bash
The one before the accident
-rw-r--r-- 1 ovidiu users 223237 Sep 12 13:13 script_nou_julia.bash
3012 lines of code lost on the sync 👎
I really admire what your trying to do, your software is unique, to bad that your clients are released without being properly tested, as i sad before: the open source community knows that is a subject of test; but what you are doing is not OK. So until your project is mature enough to have stability, i cannot rely on it, so I'm going to use a commercial free application.
Thank you for what you did until now.
Ovidiu

[woutervanrooy]

Yeah sure, after all this ranting just close the issue. After all, you are the only one facing the problem isn't it? I happen to be a happy ownCloud user, but would like to see this issue fixed. Could someone please re-open the issue?

[covidium]

@woutervanrooy so I am the only one who has this problem? do you read the entire page? or just my last post?

[woutervanrooy]

@covidium No, you're not the only one facing this issue or other bugs in the ownCloud software. There is an easy workaround for this specific problem though, by simply using the 1.1.4 sync client until a proper fix is available.

What I meant with my comment earlier today, is that you should not open an issue and then simply close it if things are not progressing quickly enough for you. The bug still exists and there is some useful info in other comments, which you would rule out by closing the bug report.

[Berglucht]

I have the same problem after updating to the 1.20 sync client on windows 7 X64. To get an idea what might go wrong I changed the loglevel on my apache server to debug and got he error:

[Thu Feb 14 14:28:35 2013] [debug] ssl_engine_io.c(1908): OpenSSL: I/O error, 5 bytes expected to read on BIO#7f0bf7180b00 [mem: 7f0bf7186163]

after which the owncloud client log says:

** error Strings: ("CSync processing step propagate failed.
Backend Message: Could not read response body: connection was closed by server")

could this be a SSL problem?

[danimo]

@Berglucht Can you check if it foes away with a recent snapshot from http://download.owncloud.com/download/nightly/ ?

[Berglucht]

I installed latest nightly(13 feb), but still got the same error messages on both the server and client.

[danimo]

For the records: could be an apache issue: http://apache-http-server.18135.n6.nabble.com/Apache-SSL-reverse-proxy-for-chunked-content-seems-to-be-broken-td4999156.html

[dragotin]

On 25.02.2013 21:20, icewind1991 wrote:

Afaik the incorrect size for zip files was fixed a few releases ago, maybe the entry in the cache is older then that

Robin, can we have bug-workaround code for the problem, ie. some code
that recalculates the size of zips if these are queried from the
fscache? Or a complete recalc of the file cache if that seems more
efficient? This problem is harming quite a few people.

Thx,

Klaas

---

Reply to this email directly or view it on GitHub:
#272 (comment)

[icewind1991]

@mihl it will rebuild the cache

[mihl]

@icewind1991 : And will that fix the size discrepancy?

[icewind1991]

I think so

[mihl]

@icewind1991 is there any downside to that solution? I have ALOT of users on my ownCloud installation...

[ronnystandtke]

Unfortunately, I have to join in here. I just upgraded both the owncloud server and client to the latest official versions and syncing now always fails with the following messages in the log window:

02-25 23:14:03:445 oc_module: => open called for owncloud://anon.net/owncloud/remote.php/webdav/clientsync/Beruf/PH_FHNW/SAI/neues Angebot/SO_SAI_Rahmenvertragsdokumente.zip
02-25 23:14:03:445 oc_module: GET request on /owncloud/remote.php/webdav/clientsync/Beruf/PH_FHNW/SAI/neues%20Angebot/SO_SAI_Rahmenvertragsdokumente.zip
02-25 23:14:03:445 oc_module: Sendfile handling request type GET.
02-25 23:14:03:445 oc_module:   -- GET on owncloud://anon.net/owncloud/remote.php/webdav/clientsync/Beruf/PH_FHNW/SAI/neues Angebot/SO_SAI_Rahmenvertragsdokumente.zip
02-25 23:14:03:477 oc_module: Content encoding ist <empty> with status 200
02-25 23:14:08:527 oc_module: Neon error code was 1
02-25 23:14:08:527 oc_module: Error GET: Neon: 1, errno 10013
02-25 23:14:08:527 _csync_push_file: file: owncloud://anon.net/owncloud/remote.php/webdav/clientsync/Beruf/PH_FHNW/SAI/neues Angebot/SO_SAI_Rahmenvertragsdokumente.zip, command: sendfile, error: Unbekannter Fehler 10013 from errno 10013
02-25 23:14:08:528 _csync_propagation_file_visitor: FAIL NEW: Beruf/PH_FHNW/SAI/neues Angebot/SO_SAI_Rahmenvertragsdokumente.zip
02-25 23:14:08:528 csync_propagate: Propagation for remote replica took 5.08 seconds visiting 863 files.
02-25 23:14:08:528  #### ERROR csync_propagate:  "CSync Verarbeitungsschritt "Übertragung" fehlgeschlagen.<br/>Systemnachricht:Konnte Rumpf der Antwort nicht lesen: connection was closed by server" 
02-25 23:14:08:529 csync_lock_remove: Removing lock file: /home/ronny/.local/share/data//ownCloud//lock
02-25 23:14:08:530 CSync run took  8200  Milliseconds 
02-25 23:14:08:535 -> CSync Finished slot with error  true 
02-25 23:14:08:535   ** error Strings:  ("CSync Verarbeitungsschritt "Übertragung" fehlgeschlagen.<br/>Systemnachricht:Konnte Rumpf der Antwort nicht lesen: connection was closed by server") 
02-25 23:14:08:535     * owncloud csync thread finished with error 
02-25 23:14:08:535 Starting Event logging again in  2000  milliseconds 
02-25 23:14:08:535 OO folder slotSyncFinished: result:  4  local:  false 
02-25 23:14:08:535 ==> load folder icon  "owncloud-framed" 
02-25 23:14:08:535 Returning configured owncloud url:  "http://anon.net/owncloud/remote.php/webdav/" 
02-25 23:14:08:535 Folder in overallStatus Message:  Mirall::ownCloudFolder(0x13c1d00)  with name  "ownCloud" 
02-25 23:14:08:535 Sync state changed for folder  "ownCloud" :  "Error" 
02-25 23:14:08:535 *  "ownCloud" Poll timer enabled with  28519 milliseconds 
02-25 23:14:08:535 <===================================== sync finished for  "ownCloud" 
02-25 23:14:08:736 XX slotScheduleFolderSync: folderQueue size:  0 
02-25 23:14:10:535     * event notification  enabled 
02-25 23:14:17:347 #============# Status dialog starting #=============# 
02-25 23:14:17:347 Folder:  Mirall::ownCloudFolder(0x13c1d00) 
02-25 23:14:17:347 ==> load folder icon  "owncloud-framed" 
02-25 23:14:17:348 Returning configured owncloud url:  "http://anon.net/owncloud/remote.php/webdav/" 
02-25 23:14:17:362 Check status.php from statusdialog. 
02-25 23:14:17:362 Get Request to  "status.php" 
02-25 23:14:17:362 Returning configured owncloud url:  "http://anon.net/owncloud/" 
02-25 23:14:17:362 Returning configured owncloud url:  "http://anon.net/owncloud/" 
02-25 23:14:17:362 Setting up host header:  "anon.net" 
02-25 23:14:17:393 status.php returns:  "{"installed":"true","version":"4.90.8","versionstring":"4.5.7","edition":""}"   0  Reply:  QNetworkReplyImpl(0x15b2f80) 
02-25 23:14:17:393 Unknown info from ownCloud status.php:  "installed" = "true" 
02-25 23:14:17:393 #-------# oC found on  "http://anon.net/owncloud" 
02-25 23:14:19:348 Toggle enabled/disabled Folder alias  "ownCloud"  - current state:  true 
02-25 23:14:19:348 Application: enable folder with alias  "ownCloud" 
02-25 23:14:19:348     * event notification  disabled 

Looks like another problem with zip files...

[WitoldA]

@icewind1991 Thank you for the information. Unfortunately it did not help in my case, but something interesting turned out.

First, I tried executing scanFiles(true) as you have suggested. The scanning entered into an endless loop. I aborted rescanning (by logging out) and tried to synchronize the files. It didnt work.

Second, I tried deleting everything from table oc_fscache (after backing up its contents of course). After logging into owncloud, thefile scanning started on its own and entered the endless loop as the last time. Scanning always stopped at a compressed (tar.bz2) file. After logging out to abort the rescanning I checked the oc_fscache table. It contained much less entries than previously - obviously not every file was scanned and entered into the table (for example there was no paczka2.zip entry).

Third, I restored the original contents of the oc_fscache table. After relogging no rescanning started, ie. I returned to the starting point.

Is there a way to get some log from scanFiles procedure so that we may check what causes endless abort and restart?

EDIT: I checked the number of files in all of the accounts. I have the following observations:
Original oc_fscache table had about 2158 files,
The number of files in all of the accounts is around 1494 (not counting directories)
The number of entries in the partially regenerated oc_fscache 506

[icewind1991]

It sounds like it it problem with scanning the archive, you can temporary disable archive support

[WitoldA]

@icewind1991 That helped! Thanks :) Disabling archive support allowed the scanFiles procedure to finish. Moreover file synchronization works now. If I can be of some help in rooting out the bug please let me know ;)

EDIT: typo

[Dusa]

Where can I disable archive support? Is this a clientside setting?

[WitoldA]

Its a server side setting. Log in to your owncloud account (through web browser). Choose settings/applications (or similar - I was translating from my own language), find archive support and turn it off. I dont know if you need an admin account for that or not (I have one).

[tbelliard]

Disabling archive support and triggering scanFiles also solved the problem on my setup. Everything is now working properly. Hard to tell though whether this was just a consequence of past bugs or something new.

[fiasko]

Same problem still here with ownCloud 1.2.1. One large (.mkv) file in the server and the OC client is unable to sync it to the Windows computer. "CSync processing step propagate failed." error just keeps coming.

[mkormendy]

so what's happening with this issue?

[andres-asm]

I guess disabling archive support is a workaround but hardly a fix...

[dragotin]

I created #owncloud/core#2102 to track this on server side.

[andres-asm]

thanks
On Mar 5, 2013 3:25 AM, "dragotin" notifications@github.com wrote:

I created #owncloud/core#2102 to track this on server side.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/272#issuecomment-14428512
.

[Atrejoe]

Archive support is disabled, server contains only small files (and not even a lot).
I have sync client 1.2.1 on (Windows 8 x64), running ownCloud 4.5.7 on QNap TS-410, I receive the same error, anything I can share for debugging purposes?

[fiasko]

Same issue remains even though I disabled the archive support.

[WitoldA]

@fiasko Did you try running scanFiles procedure after disabling archive support? The archive support just wasnt allowing this procedure to finish.

[doomi]

it began to happen at me a few days ago with 4.5.5 and client 1.2 (win & OSX). I updated to 4.5.7 and 1.2.1 with no success.

the cause for me are zip files containing PDFs.
I can randomly zip a PDF and I'll get the error. renaming the zip to anything other (.txt or .jpg) fixes it.
a zip containing a JPG or TXT does seem to work, though...

[WitoldA]

The ZIP file which caused problems for me also contained PDF file.

[guillermomarco]

I'm also getting this issue on owncloud 5 with oC 1.2.1 for ubuntu.
Happens with large files 5GB +

I can't find where to disable archive support.

[CatoTH]

I faced the (assumedly) same as described here with OwnCloud 4. Now, since 5.0.0, the Sync client does not produce error messages any more. Therefore, a major part of the files are deleted, on the server as well as on the client.
This happened on a sync folder newly created on 5.0.0. The initial sync with one device worked - the problem occurred with the second device trying to sync.
Sync Client is 1.2.1 on Ubuntu.

[danimo]

Should be fine now with file chucking and the zip file problem fixed (5.0.8 has an improved trigger_rescan() implementation). Closing.

[Steuf]

Don't know if is the same bug, but I have resolved my problem like that with this patch : http://forum.owncloud.org/viewtopic.php?f=26&t=21541