<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p></p>
<div>Package: csync2</div>
<div>Version: 2.0-42-g83b3644-3</div>
<div>Severity: important</div>
<div>Tags: patch upstream</div>
<div><br>
</div>
<div>Hi,</div>
<div><br>
</div>
<div>Following up on our mail exchange here is the report you asked for.</div>
<div><br>
</div>
<div>On a GnuTLS build, a large synchronisation never finishes in one run. It aborts <span style="font-size: 12pt;">after roughly 7.4 GiB moved over a single connection, with</span></div>
<div><br>
</div>
<div>    Read-error while receiving data.      # receiving node</div>
<div>    Write-error while sending data.       # sending node</div>
<div><br>
</div>
<div>and resumes where it stopped on the next run. Pushing ~31 GB / 56k files to two <span style="font-size: 12pt;">peers took seven runs of csync2 to converge.</span></div>
<div><br>
</div>
<div>What ruled out a flaky link is that the abort point is deterministic: 8.0 GB, <span style="font-size: 12pt;">then 15.4 GB, then 22.9 GB transferred, the same figures on two different peers</span></div>
<div>and again after rebuilding the package from source.</div>
<div><br>
</div>
<div>I patched READ() and WRITE() in conn.c to log what GnuTLS actually returns <span style="font-size: 12pt;">before csync2 gives up. Both ends report the same thing:</span></div>
<div><br>
</div>
<div>    sender:   rc=-28 (Resource temporarily unavailable, try again.) count=512</div>
<div>    receiver: rc=-28 (Resource temporarily unavailable, try again.) fatal=0 count=512</div>
<div><br>
</div>
<div>-28 is GNUTLS_E_AGAIN, and gnutls_error_is_fatal() returns 0 for it. csync2 <span style="font-size: 12pt;">passes the negative return up the stack anyway: conn_read() turns it into a</span></div>
<div>short read and csync_recv_file() calls csync_fatal(), while on the other side <span style="font-size: 12pt;">csync_send_file() sees rc != chunk and does the same.</span></div>
<div><br>
</div>
<div>Worth noting because it cost me a test run: patching only the sending side <span style="font-size: 12pt;">changes nothing at all, </span><span style="font-size: 12pt;"> same seven runs, same thresholds, </span><span style="font-size: 12pt;"> because the
 receive</span></div>
<div>path then aborts on the identical condition. Both need fixing.</div>
<div><br>
</div>
<div>With both patched, the same 31.66 GB to two peers goes through in a single run, <span style="font-size: 12pt;">1938 s, no aborts. I verified the result each time by comparing an md5 digest of </span><span style="font-size: 12pt;">the whole tree on all
 three nodes.</span></div>
<div><br>
</div>
<div>The patch is attached (DEP-3 header included). It applies to the packaging <span style="font-size: 12pt;">source as-is, and to current upstream master (253bfc48) with offsets of +3 and</span></div>
<div>-4 lines.</div>
<div><br>
</div>
<div>Reported upstream as https://github.com/LINBIT/csync2/issues/45. Another user <span style="font-size: 12pt;">has since confirmed there that the bug matches long-standing trouble they had</span></div>
<div>with large files, and that building with the patch fixes it for them.</div>
<div><br>
</div>
<div>Also worth mentioning while you are looking at the package: the security tracker <span style="font-size: 12pt;">still lists trixie as open for CVE-2026-41051, fixed from -6 onwards.</span></div>
<div><br>
</div>
<div>Happy to test anything else, I still have the three-node setup.</div>
<div><br>
</div>
<div>Regards,</div>
<div>w4zu <kevin@w4zu.ovh></div>
<div><br>
</div>
<br>
<p></p>
</div>
</body>
</html>