<div dir="ltr">Thanks Kevin. <div><br></div><div>I tried leaving off --fileflags and got entirely different error output:</div><div><br></div><div>rsync: [generator] failed to set file flags on "/Users/redacted/Library/Accounts": Operation not permitted (1)<br></div><div><br></div><div>In this example, the Library subdir on the source has the "hidden" flag set; my understanding of this error is that it is not able to set that flag on the destination.</div><div><br></div><div><font face="monospace"># ls -laO@ /Users/redacted/Library<br>total 96<br>drwx------@   72 502  staff  hidden   2448 Oct  8 18:27 .<br></font></div><div><br></div><div><br></div><div>When I checked the Library subdir on the destination after copying, it was indeed missing the hidden flag.</div><div><br></div><div>I'm not sure how I could work around both the original error caused by using --fileflags, and this error caused by omitting --fileflags.</div><div><br></div><div>Also not sure why rsync is trying to honor the hidden flag when I'm NOT using --fileflags, but that is another post for the future.</div><div><br></div><div><br></div><div>I do have a solution currently: rsync 3.0.9, the only other version I keep installed on my systems. It does not have a problem with --fileflags. So for this task I am downgrading to version 3.0.9.</div><div><br></div><div>I guess using 3.0.9 will be fine. But if anyone has any insight or cautionary advice on 3.0.9 vs 3.2.3, I want to hear it. The systems are Macs, some still with HFS+ file systems and others with APFS. </div><div><br></div><div><br></div><div>Thanks,</div><div>Fred</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 31, 2021 at 6:51 AM Kevin Korb via rsync <<a href="mailto:rsync@lists.samba.org">rsync@lists.samba.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">No, rsync normally handles such problems well.  Unfortunately,<br>
--fileflags is an OS vendor added feature rather than an official rsync<br>
feature so it is less well thought out.<br>
<br>
On 10/31/21 3:51 AM, Perry Hutchison wrote:<br>
> That sort of snafu is why find(1) has the -depth directive.<br>
> Does rsync have anything similar?<br>
> <br>
> Kevin Korb via rsync <<a href="mailto:rsync@lists.samba.org" target="_blank">rsync@lists.samba.org</a>> wrote:<br>
> <br>
>> There maybe a proper solution but an obvious workaround would be to run<br>
>> rsync twice.  The first time without the --fileflags option.<br>
>><br>
>> --no-perms wouldn't help.  That is only the standard unix permissions.<br>
>><br>
>> On 10/30/21 8:04 PM, Fred Fugate via rsync wrote:<br>
>>> Hi,<br>
>>><br>
>>> I have some subdirectories within a home directory that are chflagged<br>
>>> schg, aka system immutable.<br>
>>><br>
>>> When I rsync the home directory to another machine, I get lots of errors<br>
>>> for these subdirectories and they fail to copy to the target. NOTE: The<br>
>>> target is empty; rsync is copying to an empty remote machine, not trying<br>
>>> to overwrite anything.<br>
>>><br>
>>> I understand why this is happening; it's the schg flag. But is there a<br>
>>> workaround using some combination of rsync options or multiple passes?<br>
>>><br>
>>> Here is an example.<br>
>>><br>
>>> The source directory is /Users/redacted.<br>
>>><br>
>>> Within /Users/redacted is a subdirectory foo that has flag schg set:<br>
>>> /Users/redacted/Documents/artwork/foo<br>
>>><br>
>>> # ls -laO /Users/redacted/Documents/artwork<br>
>>> total 80<br>
>>> drwxr-xr-x ?? 20 redacted ??staff ??- ?? ?? ?? ??680 Sep 21 21:06 .<br>
>>> drwx------@ 609 redacted ??staff ??- ?? ?? ??20706 Oct 29 16:07 ..<br>
>>> -rw-r--r--@ ?? 1 redacted ??staff ??- ?? ?? ??18436 Sep 21 20:55 somefile<br>
>>> drwxrwxrwx@ ??18 redacted ??staff ??schg ?? ?? 612 Apr 12 ??2006 foo<br>
>>><br>
>>><br>
>>> My rsync args are:<br>
>>><br>
>>> --verbose --archive --one-file-system --acls --hard-links --xattrs<br>
>>> --protect-args --delete-after --numeric-ids --itemize-changes --crtimes<br>
>>> --fileflags --force-change<br>
>>> --rsync-path=/opt/rsync323/bin/rsync<br>
>>><br>
>>> My rsync version is 3.2.3<br>
>>><br>
>>> My execution and output looks like this, run as root:<br>
>>><br>
>>> # /opt/rsync323/bin/rsync [ARGS ABOVE] /Users/redacted<br>
>>> remotemachine.domain.com:/Users<br>
>>> .<br>
>>> .<br>
>>> rsync: [receiver] mkstemp<br>
>>> "/Users/redacted/Documents/artwork/foo/bar/.background.tiff.vYOAS2"<br>
>>> failed: Operation not permitted (1)<br>
>>> rsync: [receiver] mkstemp<br>
>>> "/Users/redacted/Documents/artwork/foo/bar/.dc4.orange.CMYK.tiff.rYCmAP"<br>
>>> failed: Operation not permitted (1)<br>
>>> rsync: [receiver] mkstemp<br>
>>> "/Users/redacted/Documents/artwork/foo/bar/.barcode.tiff.2E4mec" failed:<br>
>>> Operation not permitted (1)<br>
>>> .<br>
>>> .<br>
>>><br>
>>> In a nutshell:<br>
>>><br>
>>> Subdirectory foo gets created on the receiver, but it gets created with<br>
>>> the schg flag set.<br>
>>><br>
>>> No further copying into foo can happen after that, because the schg flag<br>
>>> prevents that.<br>
>>><br>
>>> Subdirectory bar cannot be created under foo, and<br>
>>> .background.tiff.vYOAS2 and other files cannot be created under bar, etc.<br>
>>><br>
>>> How can I force the schg flags to be set on the receiver AFTER<br>
>>> everything has been copied from the source?<br>
>>><br>
>>> I really don't want to remove all of my schg settings on the source<br>
>>> before rsyncing to the target.<br>
>>><br>
>>> Would --no-perms allow this? But what would it break?<br>
<br>
-- <br>
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,<br>
        Kevin Korb                      Phone:    (407) 252-6853<br>
        Systems Administrator           Internet:<br>
        FutureQuest, Inc.               Kevin@FutureQuest.net  (work)<br>
        Orlando, Florida                <a href="mailto:kmk@sanitarium.net" target="_blank">kmk@sanitarium.net</a> (personal)<br>
        Web page:                       <a href="https://sanitarium.net/" rel="noreferrer" target="_blank">https://sanitarium.net/</a><br>
        PGP public key available on web site.<br>
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,<br>
<br>
-- <br>
Please use reply-all for most replies to avoid omitting the mailing list.<br>
To unsubscribe or change options: <a href="https://lists.samba.org/mailman/listinfo/rsync" rel="noreferrer" target="_blank">https://lists.samba.org/mailman/listinfo/rsync</a><br>
Before posting, read: <a href="http://www.catb.org/~esr/faqs/smart-questions.html" rel="noreferrer" target="_blank">http://www.catb.org/~esr/faqs/smart-questions.html</a><br>
</blockquote></div>