Looking at the sparse documentation of openrsync does not create any confidence for me that it can be an acceptable substitute for rsync.

In my opinion, any program that is supposed to copy files, but which is not able to make perfect copies, i.e. copies that do not lose any bit of data or metadata that was present in the original file, is just unusable garbage.

Unfortunately, most copying programs available in UNIX-like operating systems (and also many archiving programs) do not make perfect file copies with their default options and many of them are never able to make perfect copies, regardless what options are used.

I have not looked recently at the scp command of ssh, but at least until a few years ago it was not possible to make perfect file copies with scp, especially when the copies were done between different operating systems and file systems. That is why I never use scp, but only rsync over ssh.

Rsync is the only program that I have seen, which is able (with the right options) to make perfect file copies even between different operating systems and file systems (for instance between FreeBSD with UFS and Linux with XFS), preserving also metadata like extended file attributes, access control lists and high-precision file timestamps (some copying programs and archiving programs truncate high-precision timestamps).

The current documentation of openrsync does not make any guarantee that it can make complete file copies, so by default I assume that it cannot, so for now it is a program that I consider useless.

Beside rsync for copying, one of the few Linux archiving programs that can archive perfect file copies is bsdtar (when using the pax file format; the ancient tar and cpio file formats cannot store all modern file metadata).

(FYI: I always alias rsync to '/usr/bin/rsync --archive --xattrs --acls --hard-links --progress --rsh="ssh -p XXX -l YYYYYYY"')

(With the right CLI options, "cp" from coreutils can make perfect file copies, but only if it has been compiled with appropriate options; some Linux distributions compile coreutils with wrong options, e.g. without extended file attributes support, in which case "cp" makes only partial file copies, without giving any warnings or errors.)

As a relatively new Linux user, I often find the "versioning" of bundled system utilities also to be a bit of a mess, for lack of a better word.

A classic example, at least from my experience, is `unzip`. On two of my servers (one running Debian and the other an older Ubuntu), neither of their bundled `unzip` versions can handle AES-256 encrypted ZIP files. But apparently, according to some Stack Overflow posts, some distributions have updated theirs to support it.

So here is what I ran into:

1. I couldn't easily find an "updated" version of `unzip`, even though I assume it exists and is open source.

2. To make things more confusing, they all claim to be "version 6.00", even though they obviously behave differently.

3. Even if I did find the right version, I'm not sure if replacing the system-bundled one is safe or a good idea.

So the end result is that some developer out there (probably volunteering their time) added a great feature to a widely used utility, and yet I still can’t use it. So in a sense, being a core system utility makes `unzip` harder to update than if it were just a third-party tool.

I get that it's probably just as bad if not worse on Windows or macOS when it comes to system utilities. But I honestly expected Linux to handle this kind of thing better.

(Please feel free to correct me if I’ve misunderstood anything or if there’s a better way to approach this.)

On one hand, it's a little annoying that openrsync doesn't support some features that rsync does.

On the other hand, it's great that there are multiple independent implementations of rsync now. It means that it's actually being treated as a protocol, not just a piece of software.

Patches to mainline rsync added support for extended attributes, particularly for supporting macOS metadata.

Bombich "Carbon Copy Cloner" is a GUI app that wraps it.

https://support.bombich.com/hc/en-us/articles/20686446501143...

I started following Mike Bombich from his posts on macOS Server sysadmin boards; see

https://web.archive.org/web/20140707182312/http://static.afp...

Nathaniel Gray created a testing tool to verify the fidelity of backups; files with multiple streams, extended attributes and ACLs, all the good stuff... Backup Bouncer:

https://github.com/n8gray/Backup-Bouncer

See also this SwiftUI app that wraps rsync, RsyncX.

https://github.com/rsyncOSX/RsyncOSX

We used to really care about this stuff, back when we were still running software from "Classic" macOS on top of our new UNIX systems.

https://web.archive.org/web/20161022012615/http://blog.plast...

So, anyone got a good resource on why Apple is so afraid of GPLv3? Surely this shouldn't be a problem as long as they statically compile the executables?