5/30/2026 at 4:41:15 PM
I've been using openrsync here and there since it was announced and it's definitely improved over time. I'm looking forward to when I can use it exclusively.The one place in my usage where it doesn't match Samba rsync is with the following:
openrsync --rsync-path=openrsync -av -e ssh /etc/services example.com:/tmp/services
I would expect openrsync to create a remote file /tmp/services, but instead it creates /tmp/services/services.
Normal directory mirroring as in -av -e ssh /path/to/src/ example.com:/path/to/dst/ works as it does with Samba rsync.
by Panino
5/30/2026 at 7:07:26 PM
> The one place in my usage where it doesn't match Samba rsync is with the following:> openrsync --rsync-path=openrsync -av -e ssh /etc/services example.com:/tmp/services
This appears to match "normal" `rsync` behavior as well. I think you need a trailing slash after `services` to sync only the contents.
EDIT: actually my "normal" rsync is openrsync on macOS...
by wtetzner
5/30/2026 at 11:12:27 PM
This switch happened in macOS 15.4, it was pretty easy to miss.by krelas
5/31/2026 at 6:30:47 AM
sounds like a compliment to the implementationby sudoshred
5/31/2026 at 3:23:27 PM
Or more likely that prior to 15.4, macOS was using an ancient version of rsync because Apple wants to avoid the GPL 3.0. rsync went GPL 3.0 in 2007.by wpm
5/31/2026 at 3:56:14 AM
Nonetheless, this matches vanilla rsync.by dcrazy
5/31/2026 at 2:44:12 PM
No, it doesn't.I think some people may not be reading closely. On Unix, "/etc/services" is a file, not a directory:
$ file /etc/services
/etc/services: ASCII text
rsync -av -e ssh /etc/services example.com:/tmp/services
The above command creates a mirror of the local file /etc/services in a remote file called /tmp/services. The outcome is exactly the same as if I had run "scp /etc/services example.com:/tmp/services"
client$ sha256 -q /etc/services
469d28e72ed0e0994d31b555cc1bed7bc95a23fd1beeb30062affb64db0dd44a
server$ sha256 -q /tmp/services
469d28e72ed0e0994d31b555cc1bed7bc95a23fd1beeb30062affb64db0dd44a
The above command creates a mirror of the local file /etc/services in a remote file called /tmp/services/services. The outcome is NOT the same as if I had run "scp /etc/services example.com:/tmp/services"
Please note that "/tmp/services" and "/tmp/services/services" are different.
client$ sha256 -q /etc/services
469d28e72ed0e0994d31b555cc1bed7bc95a23fd1beeb30062affb64db0dd44a
server$ sha256 -q /tmp/services
sha256: /tmp/services: read error: Is a directory
server$ sha256 -q /tmp/services/services
469d28e72ed0e0994d31b555cc1bed7bc95a23fd1beeb30062affb64db0dd44a
rsync -av -e ssh /etc/services example.com:/tmp/services
The above command creates a mirror of the local file /etc/services in a remote file called /tmp/services. The outcome is exactly the same as if I had run "scp /etc/services example.com:/tmp/services"
If you disagree, please state what operating systems you're using and copy/paste the output of the following commands on each side:
uname -a
rsync -V
openrsync -V
$ rsync -V
rsync version 3.4.3 protocol version 32
(snipped)
$ openrsync -V
openrsync 0.1 (protocol version 27)
openrsync --rsync-path=openrsync -av -e ssh /etc/services example.com:/tmp/services
And then type "file /tmp/services" on the remote server.
by Panino
5/30/2026 at 5:11:22 PM
Was there already a /tmp/services directory on the dest?One of the biggest points of confusion with rsync is how directories and trailing slashes are handled.
by genxy
5/30/2026 at 6:38:42 PM
I hear that a lot, but I familiarized myself with it once and ever since it makes a lot of sense to me.Source ending in “/“: You want what’s inside. Source not ending in “/“: You want the thing (i.e. directory itself). For the destination, it does not matter whether it ends in “/“ or not, but for consistency I like adding a “/“ anyway (I want to put thing inside the directory).
by anyfoo
5/30/2026 at 9:38:56 PM
Yes, the nice thing about dest having a trailing "/" is that if it exists and is NOT a directory, you are alerted right away.by linsomniac
5/30/2026 at 7:07:52 PM
It's a big source of confusion with cp. One of the UI reasons to use rsync (for mundane non-remote copying) is that it doesn't do different things based on what's present on the target.by eichin
5/30/2026 at 5:32:17 PM
> Was there already a /tmp/services directory on the dest?No. And just to make sure, I ran a quick 'rm -rf /tmp/services' on the remote host, then re-ran openrsync on the client. Same result. This is OpenBSD 7.9 on both sides.
And I 100% agree about trailing slashes.
by Panino
5/30/2026 at 6:33:15 PM
If you use a trailing slash on the source it copies from the directory, if you omit the trailing slash it copies the directory itself. AFAIK this is pretty standard across POSIX toolsby hilsdev
5/30/2026 at 9:00:11 PM
It's not, for example cp -R doesn't change behavior on the basis of a trailing slash on directory names.by SoftTalker
5/31/2026 at 2:59:44 PM
I was implementing something recently and stumbled across that cp difference. ugh.the trailing slash is pretty convenient.
by m463
5/31/2026 at 6:50:48 PM
that's not a cp difference, cp is the granddaddy hereI think trailing / could be a nice way to indicate some meaningful difference, but since autocomplete always sticks it in, just feels like a bad idea to me. I might like it if directory names always had to have a trailing /, but I am less motivated by "convenience of common cases" and much more by "absolute precision/specificity/unambiguity" belt and suspenders.
(kind of unrelated but along the same lines, I toy with the idea of getting rid of . and .. visible in the filesystem, and make them only part of the syntax of paths. then you could have unambiguous multiple links to a directory: ".. is where you came from" and .. in the root is still the root, so chroot works too)
by fsckboy
5/31/2026 at 7:05:59 PM
I think . and .. are useful. there's also perforce's ... which I find interesting (for example foo/... means everything below directory "foo")by m463
5/30/2026 at 5:17:32 PM
> I would expect openrsync to create a remote file /tmp/services, but instead it creates /tmp/services/services.As someone who has also suffered uncountable years of abuse from rsync, I understand the impulse, but I think it makes a lot more sense (and is a safer default) to create a second ”services”.
If we have a chance to change rsync defaults to something less insane and save future generations from this mess I think we should.
by hnarn
5/30/2026 at 5:29:50 PM
We don't, since we're not implementing a UI from scratch, we're matching something else.Of the two possible worlds where in one this reimplementation matches what some see as annoyances in the interface or in another they mostly match the interface except for a few cases where the purposefully diverge (for no good technical reason), IMO the latter is far worse and causes more enexpected behavior.
At most, add a special flag to opt into different default behavior so nobody is surprised by running the same command on different systems and getting different behavior.
by kbenson
5/31/2026 at 3:27:26 AM
To be absolutely clear, since on reading this later it may come across as me masquerading as part of the OpenBSD project, I am not affiliated with them. My "We don't" was in response to "If we have a chance to change rsync defaults" which we, as the general public and users (and very likely also any reimplementors) don't have that chance, because rsync has a solid UI that people and tools have integrated for over a decade, and that's not something you can just change.by kbenson
5/31/2026 at 4:04:45 AM
you responded to a comment that states "we should", your comment is a clear response to that. at least i understood it as intended.by em-bee