![使用 Acronis True Image 和 rsync 克隆的镜像驱动器错误地检测到已更改的文件,windows rsync 3.0.7 cygwin windows](https://linux22.com/image/657075/%E4%BD%BF%E7%94%A8%20Acronis%20True%20Image%20%E5%92%8C%20rsync%20%E5%85%8B%E9%9A%86%E7%9A%84%E9%95%9C%E5%83%8F%E9%A9%B1%E5%8A%A8%E5%99%A8%E9%94%99%E8%AF%AF%E5%9C%B0%E6%A3%80%E6%B5%8B%E5%88%B0%E5%B7%B2%E6%9B%B4%E6%94%B9%E7%9A%84%E6%96%87%E4%BB%B6%EF%BC%8Cwindows%20rsync%203.0.7%20cygwin%20windows.png)
有没有办法帮助 rsync 更好地检测文件是否相同?我使用 Acronis TrueImage 做了一个全新的全盘“克隆”镜像,之后进行了 rsync 测试,它检测到一堆文件已更改等。我从 C 盘(即桌面或文档)复制到 F: 盘/备份。我使用了:
rsync -avz --delete --chmod=ugo=rwX --modify-window=2 ...
在 eclipse 工作区的 rsync 中,它开始检测一堆 .metadata 等,我在它完成之前就将其终止了。
在我的 Documents 文件夹中,它似乎列出了一堆目录,所以也许它只是列出了目录,而没有真正检测文件?但通常当 rsync 检测到源和目标确实相同时,它会在显示通常的“发送增量文件列表”后直接退出而不输出任何内容……这正是我在 Documents 文件夹上第二次运行 rsync 时发生的情况,我确信在我成功使用 Acronis 克隆整个驱动器后,它已经是相同的了。
这是 Windows 上 rsync 的一个已知问题吗? 有没有解决方案或更好的命令行参数可供使用?
答案1
好像我找到了票。删除 --chmod=ugo=rwX,这当然意味着稍后尝试访问备份时可能会由于 Windows NTFS ACL 等原因而被拒绝权限,但我认为如果在 Linux 上查看它,Linux 的 ntfs 挂载工具将忽略这些垃圾并且不关心。如果我错了,请纠正我。
无论如何,在使用 Acronis TrueImage 实际完整克隆驱动器后,目标权限(即我的 F 驱动器)与源文件权限不一致,这仍然有点令人困惑。但我猜想,一旦我启动 Windows,它可能会以某种方式更改 F: 驱动器(C 驱动器的克隆)上的文件权限。因此,如果 Windows 以某种方式“更改”了 C 驱动器克隆的 F: 驱动器上的权限,那么 rsync 的 chmod=ugo=rwX 会检测到这一点,然后应用权限更改,这是有道理的。
我决定放弃 --chmod 参数,改用 --no-p --no-g --no-o 有了这三个参数,我就可以 rsync 忽略权限、组和所有者。而且它似乎成功了,最近克隆的 acronis trueimage 数据上不再有长长的检测到更改的文件列表。