macOS-更新脚本-从rsync2.6.9移动到3.0.6

我们正在macOS上使用

rsync

将特定用户的主目录从旧的（当前）迁移到新的计算机

用户拥有旧的计算机…我们拥有新的计算机

这两台计算机都绑定到Active Directory，我们的脚本保留UID/GID、资源分叉等

Apple bundles

rsync

2.6.9我们需要使用

-E

来“复制扩展属性”，然而不幸的是，与delta被破坏相比，

rsync

的每次运行都被视为完整运行

rsync

3修复了这一问题，能够“复制扩展属性”，而不中断后续运行…但是由于从GNU v2到GNU v3的更改

我们与苹果公司就如何将

rsync

更新到3.0.6而不中断任何开发人员的工作流程进行了磋商，他们建议我们选择一个文件夹并使用特定路径调用…因此我们选择

/Library/COMPANY/Applications/rsync

作为安装路径，其中

/Library/COMPANY/Applications/rsync/bin/rsync

成为二进制文件的路径

技术人员将ssh连接到用户的旧计算机并运行

/Library/COMPANY/Scripts/rsyncStuff.sh

，这将提示输入标准，简而言之，将运行如下命令：

/usr/bin/rsync --log-file=/Library/Logs/rsyncTransfer_${dateStamp}.log --exclude '<stuff>' --archive --verbose --delete --extended-attributes --progress --recursive --human-readable -e ssh /Users/jdoe adminUser@${NEWcomputerIpAddress}:/Users/Shared/

注意

rsync

2.6.9使用了

--扩展属性

，其中

rsync

3.0.6使用了

--xattrs--acl

。精神检查，这看起来对吗

一位同事问我们是否应该使用2.6.9版本中的

--rsync path=PROGRAM

，他不确定是否需要，因为技术人员正在调用我们的脚本，我们管理命令，包括

rsync

…健全性检查，以防万一。）

[编辑：已确认

——不需要rsync path=PROGRAM

。]

蒂亚，

---

Don

简短摘要：如果您想要扩展属性，请不要在rsyncv2和v3之间传输；选择一个，在两端使用它

更详细的解释：为了支持扩展属性（和查找器标志，以及所有其他非标准元数据HFS+支持），苹果修改了macOS附带的rsyncV2.x以使用。除了所有真实的文件外，它还将假元数据“文件”与“.\u”前缀同步——也就是说，如果您有一个名为“notes.txt”的文件，它将同步“notes.txt”和“.\notes.txt”，后者包含文件的元数据。增量传输对于主文件应该可以正常工作，但是对于元数据文件不支持；这并不重要，因为元数据文件通常非常小

另一方面，rsyncv3向标准添加了可扩展元数据。。。以完全不同和不相容的方式。我不记得我对此进行了多么彻底的测试，但是IIRC如果您尝试将扩展元数据从v3传输到v2，它将拒绝它，因为远程（v2）不支持该功能。如果你尝试从苹果的v2到v3，你会得到一堆实际的“.\u”文件，因为接收者无法识别它们是元数据

另外，关于不同的命令行选项，您是正确的，但是在v3上，您可能还需要

--ctimes

（保留创建时间）和

--fileflags

（保留标志）。尽管最后一个警告是：我遇到了v3锁定文件的问题（由于传输

uchg

file标志），然后无法设置它们的其他属性

---

就我个人而言，我更喜欢使用v3，所以我只是把它复制到我要在其中传输的计算机上。我通常将其安装为/usr/local/bin/rsync3，因此对于使用的版本没有任何歧义。

戈登·戴维森的回答非常有用

“答案”是，阅读他的回答，并根据您的环境和管理Mac的方式选择他提到的哪些选项是有用的

简言之，安装rsync3.0.6非常有魅力，而且恰巧是迈克·邦比奇（mikebombich）用于碳拷贝克隆器的版本。他现在为苹果公司工作，所以我相信他的判断

在我们的例子中，我们无法启用root，因此一旦rsync完成，就将文件夹从/Users/Shared/jdoe移动到/Users/jdoe，并递归地将owner设置为jdoe

乔治·戴维森的建议真的让人大开眼界，特别是关于为什么/Users/jdoe（在旧计算机上）rsync到/Users/shared/jdoe（在新计算机上）必须递归设置为jdoe作为所有者的结束语。我们必须这样做的原因是我们不能启用root，但是有些人可能能够启用root，这将使rsync进程的步骤更少

这是我们经过测试的最终命令…一如既往，我们始终希望改进我们的流程，因此我们愿意接受未来的任何建议/更改：

/Library/COMPANY/Applications/rsync/bin/rsync --rsync-path=/Library/ATOS/Applications/rsync/bin/rsync --log-file=${logFolder}/rsyncTransfer_${dateStamp}.log --exclude '.Trash' --exclude '.DS_Store' --exclude 'Library/Caches' --exclude 'Library/Keychains' --exclude 'Library/Saved Application State' --exclude 'Box Documents' --exclude 'Box Sync' --archive --verbose --acls --xattrs  --delete --progress --recursive --human-readable -e ssh /Users/${userName} ${adminName}@${ipAddress}:/Users/Shared/

rsync完成后，运行

sudo mv/Users/Shared/${username}/Users/${username}

和

sudo chown-R${username}/Users/${username}

并让用户登录

---

再次感谢戈登·戴维森为我们提供的所有精彩的输入

您好，Gordon，是的，我们在两端都使用了rsync3.0.6，我想

--rsyncpath=PROGRAM

选项令人困惑。没有它，第一次同步效果很好。没有它，第二次同步无法工作：

--rsync path=/Library/COMPANY/Applications/rsync/bin/rsync

FWIW，使用

-E

在2.6.9版中工作，但会中断增量同步…因此每次运行都是完全运行。明天我将再次尝试，看看是否已满，然后是delta，两者都可以根据需要工作，并将发布回这里。好的，delta完成的速度比我想象的要快。因此，完整版本不需要使用

--rsync path=PROGRAM

，但增量版本需要它。现在我需要弄清楚为什么主目录由执行

ssh

的帐户拥有。当我们使用2.6.9进行设置时，文件夹的UID/GID被保留。3.0.6似乎将其更改为

ssh

帐户。我想知道你是不是

/Library/COMPANY/Applications/rsync/bin/rsync --rsync-path=/Library/ATOS/Applications/rsync/bin/rsync --log-file=${logFolder}/rsyncTransfer_${dateStamp}.log --exclude '.Trash' --exclude '.DS_Store' --exclude 'Library/Caches' --exclude 'Library/Keychains' --exclude 'Library/Saved Application State' --exclude 'Box Documents' --exclude 'Box Sync' --archive --verbose --acls --xattrs  --delete --progress --recursive --human-readable -e ssh /Users/${userName} ${adminName}@${ipAddress}:/Users/Shared/