rsync，'uid/gid impossible to set' 案例导致未来的硬 link 失败，如何解决？
rsync, 'uid/gid impossible to set' cases cause future hard link failure, how to fix?
我正在使用 rsync 版本 3.1.1 协议版本 31 和 cygwin 版本 2.3.1(0.291/5/3)。
我认为我需要在第一个 rsync 运行 之前对所有 Win7 文件进行 chown，这些文件具有未知的 uid/gid，rsync 将复制这些文件。
未知 uid/gid 的 rsync 生成 'uid/gid impossible to set' 消息并复制文件，但它们不能在未来的增量备份中被硬 linked。
我尝试了很多 rsync 选项来解决这个问题，但都没有成功。
我该怎么做？
我认为这是因为当我在我的增量备份（使用适当的 --link-dest=destination）上使用 rsync 创建硬 links 时，只有具有特定用户和组创建了硬 link。我有一个包含 600,000 个文件的硬盘驱动器，这些文件在通过 rsync 传输后不允许创建硬 links。我所有其他驱动器都有许多文件也以这种方式运行。这使得硬 links 的增量备份从该驱动器无用，而 'not quite right' 与其他驱动器。
这是该 Win7 驱动器上各种用户和组状态的示例：
ls -al
total 828
drwxrwx---+ 1 Unknown+User Unknown+Group 0 Dec 7 21:33 .
dr-xrwxr-x+ 1 Unknown+User Unknown+Group 0 Dec 7 20:53 ..
-rwxrwx---+ 1 Administrators None 773985 Jan 1 2012 1.txt
-rwxrwx---+ 1 Unknown+User Unknown+Group 27936 Mar 12 2009 DATtoKML.kml
1.txt 文件是通过最近在 windows 文件资源管理器中拖放而放置的。 DATtoKML.kml 文件是 600,000 个有问题的文件中的一个示例。 1.txt 文件在之后进行 rsync 和硬 linked 没有问题。
这是文件在 rsynced 之后在目标位置的样子（--link-dest 设置为之前的 rsynced 位置）：
ls -al
total 792
drwxrwxrwx 2 root root 4096 Dec 7 21:33 .
drwxrwxrwx 4 root root 4096 Dec 7 21:34 ..
-rwxrwxrwx 2 544 197121 773985 Jan 1 2012 1.txt
-rwxrwxrwx 1 root root 27936 Mar 12 2009 DATtoKML.kml
如您所见，DATtoKML.kml 并不难 link 并且将永远在每次增量 rsync 时完全传输。
此外，这些非硬link可用文件在 rsync 处理时会从 rsync 获取消息。消息是“uid/gid 无法设置”。这些不是致命错误，因为文件会复制，但似乎没有设置用户和组，因此很难link可用。
这是产生上述列表的两个 rsync：
Dale@Uva1 ~
$ rsync -av --chmod=o=rwx /cygdrive/e/DATtoKML/ root@192.168.0.11:/DataVolume/shares/DalesDesktop/e+DATtoKML/2015-12-07-FIRST
sending incremental file list
created directory /DataVolume/shares/DalesDesktop/e+DATtoKML/2015-12-07-FIRST
./
uid 4294967295 (-1) is impossible to set on "/DataVolume/shares/DalesDesktop/e+DATtoKML/2015-12-07-FIRST/."
gid 4294967295 (-1) is impossible to set on "/DataVolume/shares/DalesDesktop/e+DATtoKML/2015-12-07-FIRST/."
1.txt
DATtoKML.kml
uid 4294967295 (-1) is impossible to set on "/DataVolume/shares/DalesDesktop/e+DATtoKML/2015-12-07-FIRST/.DATtoKML.kml.eR2hUv"
gid 4294967295 (-1) is impossible to set on "/DataVolume/shares/DalesDesktop/e+DATtoKML/2015-12-07-FIRST/.DATtoKML.kml.eR2hUv"
sent 802,347 bytes received 628 bytes 1,605,950.00 bytes/sec
total size is 801,921 speedup is 1.00
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1165) [sender=3.1.1]
Dale@Uva1 ~
$ rsync -av --chmod=o=rwx --link-dest=/DataVolume/shares/DalesDesktop/e+DATtoKML/2015-12-07-FIRST /cygdrive/e/DATtoKML/ root@192.168.0.11:/DataVolume/shares/DalesDesktop/e+DATtoKML/2015-12-07
sending incremental file list
created directory /DataVolume/shares/DalesDesktop/e+DATtoKML/2015-12-07
./
uid 4294967295 (-1) is impossible to set on "/DataVolume/shares/DalesDesktop/e+DATtoKML/2015-12-07/."
gid 4294967295 (-1) is impossible to set on "/DataVolume/shares/DalesDesktop/e+DATtoKML/2015-12-07/."
uid 4294967295 (-1) is impossible to set on "/DataVolume/shares/DalesDesktop/e+DATtoKML/2015-12-07/.DATtoKML.kml.1lp4od"
gid 4294967295 (-1) is impossible to set on "/DataVolume/shares/DalesDesktop/e+DATtoKML/2015-12-07/.DATtoKML.kml.1lp4od"
DATtoKML.kml
sent 155 bytes received 559 bytes 476.00 bytes/sec
total size is 801,921 speedup is 1,123.14
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1165) [sender=3.1.1]
Dale@Uva1 ~
$
到目前为止，似乎唯一有效的方法是在我对它们进行 rsync 之前，chown 和 chgrp DATtoKML.kml 以及 Win7 驱动器上的文件父目录。这对我来说似乎不切实际，在几乎所有错误的驱动器上做起来并不难，但另一个驱动器的此类错误分散在数千个目录中。
我认为 rsync 需要这样的选项来处理 'uid/gid impossible to set' 个案例：
--uid-error=544 --gid-error=197121
或者，只要 'uid/gid impossible to set' 出现，它就应该只使用适当的用户和组（它应该从正在同步的用户那里知道）来实现未来的困难link能力。
有人想尝试使用该选项编译 rsync 版本吗？
编辑：看起来所有有问题的文件和目录都有一个 uid and/or gid 为 4294967295。作为一个临时解决方案，我将编写一个 bash 脚本，它确实在每个文件和目录上找到win7 驱动器（但仅包括将考虑我的 rsync 排除文件传输的文件）并将任何错误的 uid 更改为 544，将错误的 gids 更改为 197121。使用 544 和 197121 是因为它们是 [=73 的用户和用户组=]s rsync 命令。
这样，当我开始在我的 rsync 日志中看到这些 uid/gid 问题时，我可以再次 运行 脚本。
希望以后这个问题能有真正的答案。
使用 --usermap 和 --groupmap rsync 选项（这要求源和目标环境都使用 3.1.0 或更高版本）。就我而言，这不起作用，因为我的目的地 (WD MyCloud) 使用 3.0.9.
或
在 cygwin 下用 gcc 运行 更改 rsync 源代码（有一些 C 知识真的不难）。
我刚刚添加了 --no-owner --no-group，但消息不再显示。
这不会复制文件所有者或组，但从 Windows 系统复制时，这通常不是问题。
如果要保留 ownership/group 成员资格，可以使用 -M --fake-super 选项将它们记录为扩展属性。 （这还有其他副作用，似乎会影响复制的文件，所有这些都是可逆的，就像将符号链接更改为常规文件一样。）
记得在还原时包含相同的选项，以恢复保存的文件元数据。
朝向man rsync，-a 与-rlptgoD 的含义相同，因此也设置了-o (owner) 和-g (group)。
因此将 -a 替换为 -rlptD。
我正在使用 rsync 版本 3.1.1 协议版本 31 和 cygwin 版本 2.3.1(0.291/5/3)。
我认为我需要在第一个 rsync 运行 之前对所有 Win7 文件进行 chown，这些文件具有未知的 uid/gid，rsync 将复制这些文件。
未知 uid/gid 的 rsync 生成 'uid/gid impossible to set' 消息并复制文件，但它们不能在未来的增量备份中被硬 linked。
我尝试了很多 rsync 选项来解决这个问题，但都没有成功。
我该怎么做？
我认为这是因为当我在我的增量备份（使用适当的 --link-dest=destination）上使用 rsync 创建硬 links 时，只有具有特定用户和组创建了硬 link。我有一个包含 600,000 个文件的硬盘驱动器，这些文件在通过 rsync 传输后不允许创建硬 links。我所有其他驱动器都有许多文件也以这种方式运行。这使得硬 links 的增量备份从该驱动器无用，而 'not quite right' 与其他驱动器。
这是该 Win7 驱动器上各种用户和组状态的示例：
ls -al
total 828
drwxrwx---+ 1 Unknown+User Unknown+Group 0 Dec 7 21:33 .
dr-xrwxr-x+ 1 Unknown+User Unknown+Group 0 Dec 7 20:53 ..
-rwxrwx---+ 1 Administrators None 773985 Jan 1 2012 1.txt
-rwxrwx---+ 1 Unknown+User Unknown+Group 27936 Mar 12 2009 DATtoKML.kml
1.txt 文件是通过最近在 windows 文件资源管理器中拖放而放置的。 DATtoKML.kml 文件是 600,000 个有问题的文件中的一个示例。 1.txt 文件在之后进行 rsync 和硬 linked 没有问题。
这是文件在 rsynced 之后在目标位置的样子（--link-dest 设置为之前的 rsynced 位置）：
ls -al
total 792
drwxrwxrwx 2 root root 4096 Dec 7 21:33 .
drwxrwxrwx 4 root root 4096 Dec 7 21:34 ..
-rwxrwxrwx 2 544 197121 773985 Jan 1 2012 1.txt
-rwxrwxrwx 1 root root 27936 Mar 12 2009 DATtoKML.kml
如您所见，DATtoKML.kml 并不难 link 并且将永远在每次增量 rsync 时完全传输。
此外，这些非硬link可用文件在 rsync 处理时会从 rsync 获取消息。消息是“uid/gid 无法设置”。这些不是致命错误，因为文件会复制，但似乎没有设置用户和组，因此很难link可用。
这是产生上述列表的两个 rsync：
Dale@Uva1 ~
$ rsync -av --chmod=o=rwx /cygdrive/e/DATtoKML/ root@192.168.0.11:/DataVolume/shares/DalesDesktop/e+DATtoKML/2015-12-07-FIRST
sending incremental file list
created directory /DataVolume/shares/DalesDesktop/e+DATtoKML/2015-12-07-FIRST
./
uid 4294967295 (-1) is impossible to set on "/DataVolume/shares/DalesDesktop/e+DATtoKML/2015-12-07-FIRST/."
gid 4294967295 (-1) is impossible to set on "/DataVolume/shares/DalesDesktop/e+DATtoKML/2015-12-07-FIRST/."
1.txt
DATtoKML.kml
uid 4294967295 (-1) is impossible to set on "/DataVolume/shares/DalesDesktop/e+DATtoKML/2015-12-07-FIRST/.DATtoKML.kml.eR2hUv"
gid 4294967295 (-1) is impossible to set on "/DataVolume/shares/DalesDesktop/e+DATtoKML/2015-12-07-FIRST/.DATtoKML.kml.eR2hUv"
sent 802,347 bytes received 628 bytes 1,605,950.00 bytes/sec
total size is 801,921 speedup is 1.00
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1165) [sender=3.1.1]
Dale@Uva1 ~
$ rsync -av --chmod=o=rwx --link-dest=/DataVolume/shares/DalesDesktop/e+DATtoKML/2015-12-07-FIRST /cygdrive/e/DATtoKML/ root@192.168.0.11:/DataVolume/shares/DalesDesktop/e+DATtoKML/2015-12-07
sending incremental file list
created directory /DataVolume/shares/DalesDesktop/e+DATtoKML/2015-12-07
./
uid 4294967295 (-1) is impossible to set on "/DataVolume/shares/DalesDesktop/e+DATtoKML/2015-12-07/."
gid 4294967295 (-1) is impossible to set on "/DataVolume/shares/DalesDesktop/e+DATtoKML/2015-12-07/."
uid 4294967295 (-1) is impossible to set on "/DataVolume/shares/DalesDesktop/e+DATtoKML/2015-12-07/.DATtoKML.kml.1lp4od"
gid 4294967295 (-1) is impossible to set on "/DataVolume/shares/DalesDesktop/e+DATtoKML/2015-12-07/.DATtoKML.kml.1lp4od"
DATtoKML.kml
sent 155 bytes received 559 bytes 476.00 bytes/sec
total size is 801,921 speedup is 1,123.14
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1165) [sender=3.1.1]
Dale@Uva1 ~
$
到目前为止，似乎唯一有效的方法是在我对它们进行 rsync 之前，chown 和 chgrp DATtoKML.kml 以及 Win7 驱动器上的文件父目录。这对我来说似乎不切实际，在几乎所有错误的驱动器上做起来并不难，但另一个驱动器的此类错误分散在数千个目录中。
我认为 rsync 需要这样的选项来处理 'uid/gid impossible to set' 个案例：
--uid-error=544 --gid-error=197121
或者，只要 'uid/gid impossible to set' 出现，它就应该只使用适当的用户和组（它应该从正在同步的用户那里知道）来实现未来的困难link能力。
有人想尝试使用该选项编译 rsync 版本吗？
编辑：看起来所有有问题的文件和目录都有一个 uid and/or gid 为 4294967295。作为一个临时解决方案，我将编写一个 bash 脚本，它确实在每个文件和目录上找到win7 驱动器（但仅包括将考虑我的 rsync 排除文件传输的文件）并将任何错误的 uid 更改为 544，将错误的 gids 更改为 197121。使用 544 和 197121 是因为它们是 [=73 的用户和用户组=]s rsync 命令。
这样，当我开始在我的 rsync 日志中看到这些 uid/gid 问题时，我可以再次 运行 脚本。
希望以后这个问题能有真正的答案。
使用 --usermap 和 --groupmap rsync 选项（这要求源和目标环境都使用 3.1.0 或更高版本）。就我而言，这不起作用，因为我的目的地 (WD MyCloud) 使用 3.0.9.
或
在 cygwin 下用 gcc 运行 更改 rsync 源代码（有一些 C 知识真的不难）。
我刚刚添加了 --no-owner --no-group，但消息不再显示。
这不会复制文件所有者或组，但从 Windows 系统复制时，这通常不是问题。
如果要保留 ownership/group 成员资格，可以使用 -M --fake-super 选项将它们记录为扩展属性。 （这还有其他副作用，似乎会影响复制的文件，所有这些都是可逆的，就像将符号链接更改为常规文件一样。）
记得在还原时包含相同的选项，以恢复保存的文件元数据。
朝向man rsync，-a 与-rlptgoD 的含义相同，因此也设置了-o (owner) 和-g (group)。
因此将 -a 替换为 -rlptD。