Re: git: f0211e11c062 - main - net/rsync: Add back the FLAGS option

From: Mark Millard <marklmi_at_yahoo.com>
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