Oct 5, 2026, 11:38 AMYay. I just got hit on the nose by rsync sloprot. Somehow I had avoided it so far. The "don't worry, it's fixed in the next version. Just upgrade" response doesn't fill me with warm fuzzy feelings. I'm now pondering my options. I haven't found a clear obvious safe choice for a slop free fork yet, and switching to another implementation will involve a verification process, and possibly porting of tooling.
Can we please just keep our software working reliably?
Oct 5, 2026, 11:57 AMThing is, we're betting multiple Terabytes of data on rsync working reliably. I'm paranoid enough to regularly run checksums on a few hundred Gigabytes to make sure rsync did its job right. This is the first time *ever* that rsync has just flat out failed to do its job. I'm not impressed.
@wfk openrsync by the openbsd guys is pretty good, it’s the default on openbsd and i believe also macos
Oct 5, 2026, 11:42 AM@shrub900
Yeah, that's one of the options I considered. But as I said, that's going to require a verification and possibly porting effort to deploy.
Oct 5, 2026, 3:06 PM
@shrub900 @wfk IIRC openrsync doesn't do everything that rsync does: "but accepts only a subset of rsync's command-line arguments." https://github.com/kristapsdz/openrsync
When I read statements like that, my usual reaction is to think that I only use a sub-set of rsync's command-line arguments, so it is probably alright.
The more important thing is that the project has been going since 2019 and has not had a single release yet. The author is still, this year, warning people that it should be considered under development.
https://github.com/kristapsdz/openrsync/issues/44#issuecomment-4879472681
The README, which the author appears to be keeping up to date so this is not years-old stale information, is still saying that bringing in Apple's code is a work in progress.
@wfk good that you did the tests. I would have just trusted the tool, I didn't know rsync had rotten this badly.
Oct 5, 2026, 12:16 PM@farseen
I learned to verify my backups long ago. I've had both tape drives and CD/dvd writers slowly slip out of calibration, so they started writing media that couldn't be read on another drive.
Always verify, and not just on the device you created the backup on.
Oct 5, 2026, 4:27 PM@wfk Which version failed? We rely on rsync for quite a few things and I rather build older versions by hand than get burned by slop. It's not like rsync wasn't feature complete for our use case.
Oct 5, 2026, 4:33 PM@taf it was a known bug in 3.4.3 that lingered on a box. Apparently it was fixed in 3.4.4. I upgraded to 3.5.*, but given the history I don't feel overly confident that I won't run into another new bug in the near future, so I'm looking for a safe path forward.
One quick option is to check out 3.4.1 or some such and build my own binary.
Oct 5, 2026, 4:40 PM@taf btw, our backup tooling has been using rsync for nearly 20 years and never encountered any problem with rsync. Any problems were our own.
Imho rsync needed at most minimal security maintenance. It just worked.
@wfk I generally don't run rsync directly, but I have noticed that a number of system update and security tools seem to invoke rsync as part of their processes. It worries me what might be getting messed up by those tools, if they're written with the assumption that rsync is alwatys working correctly.
Oct 12, 2026, 9:20 PMOct 12, 2026, 9:31 PM
@wfk
Openrsync is coming along...
Oct 5, 2026, 12:14 PM@wfk any details on what to be careful around?
Oct 5, 2026, 12:42 PM@wfk (If you're not open to recommendations, let me know and I'll delete this.)
According to https://codeberg.org/ethical-foss/open-slopware#file-transferring, there is a slop-free alternative called gokrazy/rsync (or gokr-rsync). It's a minimal implementation of rsync in Go, and seems to exist specifically to avoid vulnerabilities: https://michael.stapelberg.ch/posts/2026-05-24-minimal-memory-safe-go-rsync-vulns/
Other than that, I know nothing about this project, so use at your own risk.
Here's the repo: https://github.com/gokrazy/rsync
Oct 5, 2026, 12:46 PM@teun thanks. I will be looking into alternative implementations, but our tooling is using several less commonly used capabilities of rsync, so I'll need to verify that they implement what we need. Short term I'm looking at simply a pre-slop fork.
@wfk oof. That is... Not great. I'm waiting for the same thing.
The only answer I've found? Get a preslop binary and park it in my user home bin folder. Which is to say, I have no good answer since it's so pervasive.
There's some FUD here if I read the actual history right.
3.4.3 had no AI contributed code (in theory see below). It did, however, have some regressions that were *found* by humans using AI.
In response, Andrew Tridgell used AI assistance to rewrite the test suite, moving it from shell to python and making improvements, to cover the regressions - and his commits acknowledge this. The assertion is the AI was only used for the test suite, not for the actual rsync code. It seems unlikely to me he'd acknowledge it in the test suite but hide it in the actual code.
3.4.4 is the result that should fix those regressions, although 3.5 is also coming down the pipe with "security fixes", whatever that might be.
There's no indication that any AI-assisted coding is in the actual binary. Just good old human mistakes. Unless of course people lie about their AI use, or more charitably simply omit that data from their commits. There are no hard guarantees about code provenance, but then there never were, in any project. There's also no AI policy for that project I am aware of.
Open source is open for reasons. One of those is you have no real guarantees of fitness - so here's the code, audit it yourself. I think we sometimes forget that and take the hard work of others for granted.
Oct 5, 2026, 1:22 PM@tbortels ah, I'll need to dig a bit deeper to see what the real sequence of events was. My understanding was that the instabilities started after the introduction of Claude generated code. If things had already gone south before that, I missed that bit.
Still feeling decidedly uncomfortable trusting Claude generated code is such a critical bit of software.
I tend to agree, but pragmatically - it's open source. Your alternatives also have no guarantees of provenance or quality. And closed source is worse - at least this way we could, in theory, audit.
And if I have the time line right - big If, but hey - the first introduction of AI was a flood of AI generated external bug reports, which is what prompted the revamp of the test suite. The alternatives were maybe to ignore the reports, or manually update the tests?
And I'd repeat: no AI in the mainline code *that we know of*. Guarantees there will be hard to come by. The price we pay for free code is that people do things we may not approve of or know about.
I personally backrev on purpose. The world is my beta tester. :-)
Oct 5, 2026, 3:07 PMso I checked the git log.
Claude contributions startled showing up before 3.4.2.
The version that tripped me up was 3.4.3.
So, no FUD there on my part.
The change that caused me trouble was right after Claude contributions appeared in the log. That doesn't mean necessarily that the bad code was actually written by Claude, but it does mean that it happened right after a flood of Claude changes went into the repo.
Oct 5, 2026, 1:19 PM@wfk you know far better than I, but could syncthing fulfil enough of rsync's far more robust abilities to provide even short term relief?
Oct 5, 2026, 2:33 PM@john as a colleague of mine has been saying for decades:
RAID is not a backup.
This syncthing tool provides RAID like functionality, but not automated verified nightly incremental backups.
Different problem, different solution.
I can go back a year and restore an accidentally deleted file, from any of multiple disks at multiple sites.
For RAID I use the md subsystem.
Oct 5, 2026, 8:04 PMIf you set up syncthing with staggered file versioning (https://docs.syncthing.net/users/versioning#staggered-file-versioning) it can work pretty well as a backup.
I have a desktop with a btrfs RAID partition and all our family devices use syncthing to back up photos, password databases and shared notes to it
@wfk AFAIK OpenBSD's openrsync is slop free. It's not a drop in replacement if feature parity and same API matters.
Oct 5, 2026, 1:35 PM@swinburne and that is why it's a candidate that will involve verification and possibly porting effort to make it work with our tooling.
Hence my short term preference is to work with a pre-slop fork.
Longer term, I'll need to see where the pain is between our tooling and other rsync implementations, to keep our options open.
@wfk Maybe the biggest problem of today's software engineering culture is that stale code is thoroughly undervalued. 🙁
Oct 6, 2026, 8:45 PM@brainsmoke We call them "stable packages"
Oct 6, 2026, 9:54 PM@brainsmoke
When I did my "Software Engineering" course at uni, the professor started by pointing out that the "Software Engineering" field really wasn't worthy of the "Engineering" moniker.
There was no established engineering practice to ensure that an architecture, or the resulting product, met all the necessary functional and safety requirements. Applying Software Engineering practices on a construction site would lead to instant loss of license. Not much has improved since.
@wfk It's facepalms all the way down.
@wfk there's a generational thing going on. I worked with a bunch of folks at startup XXX just starting out - very smart, very ambitious - who just don't think quality is a thing. It was astonishing, and I was the old guy flapping his gums. It was so weird, but I was the one to leave. It didn't get better, because they just wanted an exit, not customers or good code.
I'm overgeneralizing but still.
Oct 5, 2026, 2:37 PM@grechaw this has been going on for decades. Back in the 90s one of the most attractive software business models was to make enough marketing noise to get bought out by Microsoft. Actually creating shippable code was at best an afterthought.
@wfk I sure didn't like That Old Guy's spaghetti ssh tunnels back in the day. And he thought I was incredibly obnoxious what with my unit tests and IDE.
Oct 5, 2026, 7:58 PM@grechaw heh. "ssh tunnels" and "back in the day" in one sentence sounds dissonant to my ears. Back in the day, this newfangled ssh thing didn't exist yet. :-)
Oct 6, 2026, 4:10 PMOct 6, 2026, 5:31 PMOct 6, 2026, 6:57 PM
@wfk the problem is harder than “can we just do x”, but I agree it’s a problem.
Andrew shared more context about the “slop”, in case anyone missed it back in June
Oct 5, 2026, 10:33 PM
@wfk The reason we can't just keep our software working reliably is that too many people:
- See ai as just a tool and neutral
- Fell for the ai bros false marketing
- Do not see code as art(code is art btw) and that ai cannot make art only slop
- Are fascists and use the fascist slightly-better-autocorrect because it's fascist
- And/or do not realize that it is an unfit for purpose, ecocide-accelerating, labor-stealing, software-degrading, research-corrupting, privacy-invading, disinformation-producing, CSAM-generating, suicide-encouraging, mass violence-enabling, global economy-precaritizing, democracy-eroding, deskilling, brainrotting, futures-foreclosing tech product that was made by the eugenic death cult fascists who bankroll race science promoters and nazi politicians
Oct 6, 2026, 3:39 PM@wfk If you're open to trying something really different but Linux-focused, there is my hand-coded project Wyng backup which is now receiving development support from Qubes OS.
Wyng can backup data in a small fraction of the time vs what rsync or borg can achieve because local data does not have to be re-scanned/checksumed to find changes (the catch is that source data must reside in compatible CoW storage, although there's no such requirement on the back end).
Oct 6, 2026, 3:42 PM@tasket that is likely not going to work across multiple unixen, so not an option.
Oct 6, 2026, 4:58 PM@wfk For the back end storage it works fine on other Unices, it only has special requirements (Linux) for the source system.