An rsync based library for sending delta updates of files to a remote server

<p>DISCLAIMER: I am not the author of the package.</p> <p>Just stumbling upon the package. I used to implement a file transfer app in Go that needed something to reduce the time/bandwidth consumption. I didn&#39;t find this (or it didn&#39;t exist then) and ended up with a home-brewed, complicated, kind of band-aid solution. Re-inventing that incremental-update or binary-diff algorithm/protocol is harder than I thought. So I think it would probably be useful for your guys too.</p> <p>Edit: the link: <a href="https://github.com/c4milo/gsync">https://github.com/c4milo/gsync</a></p> <hr/>**评论：**<br/><br/>mwholt: <pre><p>I think you forgot to link to it.</p></pre>maddiez: <pre><blockquote> <p>And that question is left as an exercise to the readers...</p> </blockquote> <p>And my guess is <a href="https://github.com/c4milo/gsync" rel="nofollow">https://github.com/c4milo/gsync</a></p> <p>EDIT: Formatting and grammar</p></pre>int32_t: <pre><p>That&#39;s embarrassing. The link has been added now.</p></pre>Redundancy_: <pre><p>Similar: <a href="https://github.com/Redundancy/go-sync" rel="nofollow">https://github.com/Redundancy/go-sync</a> Disclaimer: I am the author of that package ;)</p></pre>int32_t: <pre><p>Nice!</p></pre>epiris: <pre><p>This has only two tests, why not just shell out to rsync? It adds a dependency outside the binary but it&#39;s widely available so I don&#39;t think it&#39;s a big concern. This lib may be perfectly implemented, but it only takes one edge case to potentially lose your data.</p></pre>int32_t: <pre><p>Yeah, it&#39;s a pity. And <a href="/u/Redundancy_" rel="nofollow">/u/Redundancy_</a>&#39;s project looks more comprehensive. </p> <p>Regarding why not to shell out to rsync, here are the reasons:</p> <ol> <li><p>The data transmission is between a non-PC device and a PC (mostly Windows). Rsync is not installed by default on either side. If I resort to rsync + my program, I have to ship at least two binaries, instead of one, on both sides. Let alone setting up a rsync server on Windows is not an option in my use case. </p></li> <li><p>The transport layer is not necessary TCP. It can be UART, USB(ACM/CDC), Bluetooth, and so on. AFAIK, rsync doesn&#39;t support that.</p></li> </ol> <p>The program I wrote also requires end-to-end file encryption, so vanilla rsync doesn&#39;t suffice.</p></pre>Redundancy_: <pre><p>Despite the project, I typically try and avoid block based methods these days. It&#39;s far more efficient to have a working understanding of the individual units of change that go into the files you want to update, and simpler and easier to scale delivering them individually using HTTP 1.0 and a CDN.</p></pre>