master at 7fef1c8 (includes #1054), Linux. Works with old_versions/rsync_3.4.1 and rsync_3.2.7.
/dev/stdin, /dev/stdout and /dev/stderr are symlinks to /proc/self/fd/N. With a pipe on the descriptor the link target is pipe:[N]. The pseudo-path handling from #1054 does not apply, because fd_pin_tail() only recognises paths spelled /proc/self/fd, /proc//fd or /dev/fd, so the target is spliced as a relative path and the open fails with ENOENT:
$ rsync -a --log-file=/dev/stdout src/ dst/ | cat
rsync: [client] failed to open log-file /dev/stdout: No such file or directory (2)
Ignoring "log file" setting.
(exit status 0, nothing logged)
$ printf 'file\n' | rsync -a --files-from=/dev/stdin src/ dst/
rsync: failed to open files-from file /dev/stdin: No such file or directory
rsync error: syntax or usage error (code 1) at main.c(1905) [client=3.5.0]
The /dev/fd spelling of the same descriptor works:
$ rsync -a --log-file=/dev/fd/1 src/ dst/ | cat
2026/09/07 23:44:27 [943874] building file list
2026/09/07 23:44:27 [943874] sent 86 bytes received 17 bytes total size 3
With stdout redirected to a regular file, --log-file=/dev/stdout works, since the target is then a real path.
The daemon is affected the same way and reports nothing. With log file = /dev/stdout in rsyncd.conf and the daemon's stdout a pipe:
$ rsync --daemon --no-detach --config=rsyncd.conf --port=12998 --address=127.0.0.1 > >(cat > out) 2> err < /dev/null
a client transfer succeeds, but out and err both stay empty. With old_versions/rsync_3.4.1 the "rsyncd version 3.4.1 starting" line and the connection log arrive in out.
Both client commands exit 0 and log / transfer with old_versions/rsync_3.4.1 and old_versions/rsync_3.2.7.
Inside a user namespace that does not map the host's root uid (unshare, bubblewrap, rootless podman), the same paths are additionally refused at /proc/self as an untrusted symlink, with a pipe or a regular file on the descriptor (same cause as #1083).
master at 7fef1c8 (includes #1054), Linux. Works with old_versions/rsync_3.4.1 and rsync_3.2.7.
/dev/stdin, /dev/stdout and /dev/stderr are symlinks to /proc/self/fd/N. With a pipe on the descriptor the link target is
pipe:[N]. The pseudo-path handling from #1054 does not apply, because fd_pin_tail() only recognises paths spelled /proc/self/fd, /proc//fd or /dev/fd, so the target is spliced as a relative path and the open fails with ENOENT:(exit status 0, nothing logged)
The /dev/fd spelling of the same descriptor works:
With stdout redirected to a regular file, --log-file=/dev/stdout works, since the target is then a real path.
The daemon is affected the same way and reports nothing. With
log file = /dev/stdoutin rsyncd.conf and the daemon's stdout a pipe:a client transfer succeeds, but
outanderrboth stay empty. With old_versions/rsync_3.4.1 the "rsyncd version 3.4.1 starting" line and the connection log arrive inout.Both client commands exit 0 and log / transfer with old_versions/rsync_3.4.1 and old_versions/rsync_3.2.7.
Inside a user namespace that does not map the host's root uid (unshare, bubblewrap, rootless podman), the same paths are additionally refused at /proc/self as an untrusted symlink, with a pipe or a regular file on the descriptor (same cause as #1083).