No, rsync normally handles such problems well. Unfortunately, --fileflags is an OS vendor added feature rather than an official rsync feature so it is less well thought out.
On 10/31/21 3:51 AM, Perry Hutchison wrote: > That sort of snafu is why find(1) has the -depth directive. > Does rsync have anything similar? > > Kevin Korb via rsync <rsync@lists.samba.org> wrote: > >> There maybe a proper solution but an obvious workaround would be to run >> rsync twice. The first time without the --fileflags option. >> >> --no-perms wouldn't help. That is only the standard unix permissions. >> >> On 10/30/21 8:04 PM, Fred Fugate via rsync wrote: >>> Hi, >>> >>> I have some subdirectories within a home directory that are chflagged >>> schg, aka system immutable. >>> >>> When I rsync the home directory to another machine, I get lots of errors >>> for these subdirectories and they fail to copy to the target. NOTE: The >>> target is empty; rsync is copying to an empty remote machine, not trying >>> to overwrite anything. >>> >>> I understand why this is happening; it's the schg flag. But is there a >>> workaround using some combination of rsync options or multiple passes? >>> >>> Here is an example. >>> >>> The source directory is /Users/redacted. >>> >>> Within /Users/redacted is a subdirectory foo that has flag schg set: >>> /Users/redacted/Documents/artwork/foo >>> >>> # ls -laO /Users/redacted/Documents/artwork >>> total 80 >>> drwxr-xr-x ?? 20 redacted ??staff ??- ?? ?? ?? ??680 Sep 21 21:06 . >>> drwx------@ 609 redacted ??staff ??- ?? ?? ??20706 Oct 29 16:07 .. >>> -rw-r--r--@ ?? 1 redacted ??staff ??- ?? ?? ??18436 Sep 21 20:55 somefile >>> drwxrwxrwx@ ??18 redacted ??staff ??schg ?? ?? 612 Apr 12 ??2006 foo >>> >>> >>> My rsync args are: >>> >>> --verbose --archive --one-file-system --acls --hard-links --xattrs >>> --protect-args --delete-after --numeric-ids --itemize-changes --crtimes >>> --fileflags --force-change >>> --rsync-path=/opt/rsync323/bin/rsync >>> >>> My rsync version is 3.2.3 >>> >>> My execution and output looks like this, run as root: >>> >>> # /opt/rsync323/bin/rsync [ARGS ABOVE] /Users/redacted >>> remotemachine.domain.com:/Users >>> . >>> . >>> rsync: [receiver] mkstemp >>> "/Users/redacted/Documents/artwork/foo/bar/.background.tiff.vYOAS2" >>> failed: Operation not permitted (1) >>> rsync: [receiver] mkstemp >>> "/Users/redacted/Documents/artwork/foo/bar/.dc4.orange.CMYK.tiff.rYCmAP" >>> failed: Operation not permitted (1) >>> rsync: [receiver] mkstemp >>> "/Users/redacted/Documents/artwork/foo/bar/.barcode.tiff.2E4mec" failed: >>> Operation not permitted (1) >>> . >>> . >>> >>> In a nutshell: >>> >>> Subdirectory foo gets created on the receiver, but it gets created with >>> the schg flag set. >>> >>> No further copying into foo can happen after that, because the schg flag >>> prevents that. >>> >>> Subdirectory bar cannot be created under foo, and >>> .background.tiff.vYOAS2 and other files cannot be created under bar, etc. >>> >>> How can I force the schg flags to be set on the receiver AFTER >>> everything has been copied from the source? >>> >>> I really don't want to remove all of my schg settings on the source >>> before rsyncing to the target. >>> >>> Would --no-perms allow this? But what would it break? -- ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._., Kevin Korb Phone: (407) 252-6853 Systems Administrator Internet: FutureQuest, Inc. ke...@futurequest.net (work) Orlando, Florida k...@sanitarium.net (personal) Web page: https://sanitarium.net/ PGP public key available on web site. ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._., -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html