Re: git: f0211e11c062 - main - net/rsync: Add back the FLAGS option
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 06 Jul 2026 22:33:49 UTC
On 7/6/26 03:09, Dag-Erling Smørg rav wrote:
> The branch main has been updated by des:
>
> URL: https://cgit.FreeBSD.org/ports/commit/?id=f0211e11c062ab148ef063283ffcc4c491a0bcc0
>
> commit f0211e11c062ab148ef063283ffcc4c491a0bcc0
> Author: Dag-Erling Smørgrav <des@FreeBSD.org>
> AuthorDate: 2026-07-06 10:08:45 +0000
> Commit: Dag-Erling Smørgrav <des@FreeBSD.org>
> CommitDate: 2026-07-06 10:08:45 +0000
>
> net/rsync: Add back the FLAGS option
>
> This restores support for copying file flags and fixes a long-standing
> peeve of mine by renaming the command-line option to --file-flags,
> better matching the naming style of other rsync options. Full backward
> compatibility is maintained, including with older servers.
>
> Reviewed by: rodrigo
> Differential Revision: https://reviews.freebsd.org/D57645
> ---
> net/rsync/Makefile | 8 +-
> net/rsync/files/extra-patch-file-flags.diff | 1382 +++++++++++++++++++++++++++
> net/rsync/files/extrapatch-main.c | 10 -
> 3 files changed, 1386 insertions(+), 14 deletions(-)
>
> . . .
I updated my ports tree and attempted to use --file-flags and
--force-update for a ZFS to UFS copy while logged in as root. I got
things like:
rsync: [generator] failed to set file flags on
"/FBSDFSSDroot-mnt/sh.core": Operation not supported (45)
(That was the first of many messages about manyfiles before I killed it.)
The ZFS file system has:
# ls -lodT /sh.core
-rw------- 1 root wheel uarch,nodump 1748992 Mar 29 09:46:40 2026 /sh.core
The result in UFS ended up with:
# ls -lodT /FBSDFSSDroot-mnt/sh.core
-rw------- 1 root wheel - 1748992 Mar 29 09:46:40 2026
/FBSDFSSDroot-mnt/sh.core
Simplifying the command used and investigating behavior some . . .
Starting with:
# ls -lodT /sh.core /FBSDFSSDroot-mnt/sh.core
-rw------- 1 root wheel - 1748992 Mar 29 09:46:40 2026
/FBSDFSSDroot-mnt/sh.core
-rw------- 1 root wheel uarch,nodump 1748992 Mar 29 09:46:40 2026 /sh.core
Attempting the following:
# rsync --file-flags --force-change -U /sh.core /FBSDFSSDroot-mnt/
rsync: [generator] failed to set file flags on
"/FBSDFSSDroot-mnt/sh.core": Operation not supported (45)
rsync error: some files/attrs were not transferred (see previous errors)
(code 23) at main.c(1376) [sender=3.4.4]
Resulted in:
# ls -lodT /sh.core /FBSDFSSDroot-mnt/sh.core
-rw------- 1 root wheel - 1748992 Mar 29 09:46:40 2026
/FBSDFSSDroot-mnt/sh.core
-rw------- 1 root wheel uarch,nodump 1748992 Mar 29 09:46:40 2026 /sh.core
But trying without the -U:
# rsync --file-flags --force-change /sh.core /FBSDFSSDroot-mnt/
Resulted in:
# ls -lodT /sh.core /FBSDFSSDroot-mnt/sh.core
-rw------- 1 root wheel uarch,nodump 1748992 Mar 29 09:46:40 2026
/FBSDFSSDroot-mnt/sh.core
-rw------- 1 root wheel uarch,nodump 1748992 Mar 29 09:46:40 2026 /sh.core
Of the command line options I originally had, it seems the -U was
the only one leading to the behavior variation.
An oddity is that:
--archive, -a archive mode is -rlptgoD (no -A,-X,-U,-N,-H)
supposedly includes -U but the result of the same sort of sequence is
like when -U was omitted.
For reference:
--atimes, -U preserve access (use) times
The -U description certainly would not lead me to guess the behavior
that I'm reporting.
--
===
Mark Millard
marklmi at yahoo.com