笔记：遗憾的是，事实证明这与文件时间戳无关。
根据给出的信息在另一篇文章中，我尝试过--modify-window=30，甚至尝试--modify-window=300过，但这并没有改变我报告的错误行为。这也与时区差异无关，因为rsync正确识别最多源文件和目标文件相同。
我正在使用rsync将大量数据从 Linux 机器上的文件系统（使用ext4文件系统的 Ubuntu 20.04）备份到 Mac 上的文件系统（使用APFS Data Volume文件系统的 Big Sur 11.7）。由于操作系统的差异，在 Linux 和 Mac 上查询时，一些相同的文件显示不同rsync。这种差异导致每次运行时源和目标之间相同的相当多的文件总是被传输rsync。
... 但不是全部文件。大多数相同的文件都不会被正确传输。但在我的 Linux 机器上的几千个文件中，源和目标之间相同的几百个文件在传输过程中始终被视为不相同的rsync。
这是我正在运行的命令...
rsync -avz -i -e 'ssh -p 6000' --ignore-errors "--exclude-from=excludes" --delete-excluded --delete-during / [email protected]:/var/backup
我也尝试了其他选项，例如--no-o，--no-g和--no-D，但仍然得到相同的结果。
这些是文件的内容excludes...
excludes
swapfile
mnt
media
tmp
opt/tmp
var/tmp
var/log
run/user
proc
dev
sys
**/lost+found*/
**/*Trash*/
**/*trash*/
**/.cache/mozilla/**
**/.cache/waterfox/**
**/brave/resources/**
**/usr/src/linux*/**
**/.mbsync/**
**/snap/**
**/snapd/**
**/flatpak/**
*.qcow2
*.iso
还 ...
根据给我的建议，我rsync通过 Homebrew 在 Mac 上重新安装，并在添加--rsync-path=/usr/local/bin/rsync到rsync命令行（这是 Homebrew 安装它的位置）后重试同步。遗憾的是，使用该 Homebrew 版本rsync无法解决问题。
而且还有……
我尝试了有和没有该选项的情况，以及与配合使用的--checksum几个不同选项。我也尝试了有和没有 的情况。这些都无法解决问题。--block-size--checksum--sparse
重复一下我之前写过的一些内容，但这些内容在我的评论中被讨论过，但被其他人删除了……
我可以rsync反复运行该命令，而源文件和目标文件均未发生任何变化，然而，完全相同的文件和目录子集在源文件和目标文件之间总是反复显示为不同，即使它们在内容、大小和时间戳方面完全相同，即使它们都完全没有变化。
所谓相同大小，是指以字节为单位测量时大小完全相同。
我强烈怀疑这种不正确的rsync行为是由于源位于 Linuxext4文件系统上而目标位于 MacOSAPFS文件系统上。我怀疑文件系统之间的这种差异会混淆所rsync使用的一个或多个文件比较算法。
嗯...也许是APFS文件系统混淆了“访问时间”和“修改时间”？
答案1
此处的情况是由目标 APFS 文件系统触发的区分大小写但不区分大小写。也就是说，您可以创建大小写混合的目录，文件系统将记录该大小写混合（例如Hippovs hippo），但在使用文件系统时会忽略大小写（因此mkdir Hippo; cd hippo会成功）。这类似于 NTFS，但与 ext4 的标准默认设置明显不同。
有两种方法可以创建 APFS 文件系统。默认的“APFS”如下所述。另一种方法是创建一个“APFS（区分大小写）”文件系统，它充当区分大小写。
考虑这个有效的 MVE。
在具有 ext4 文件系统的 UNIX/Linux 系统上运行第一部分。首先我们准备场景：
mkdir mve && cd mve
mkdir a b A; touch a/f1 # Create initial structure
( cd a; ln -s f1 s1 ) # Link to self, a/s1
( cd A; ln -s ../a/f1 s1 ) # Link to A/s1
tree # Tree structure showing symlinks
.
├── a
│ ├── f1
│ └── s1 -> f1
├── A
│ └── s1 -> ../a/f1
└── b
3 directories, 3 files
现在将文件树复制到具有 APFS 的 Mac 上：
rsync -iav . bigsurmac:mve # Copy the tree to a Mac with APFS
building file list ... done
created directory mve
cd+++++++++ ./
cd+++++++++ A/
cL+++++++++ A/s1 -> ../a/f1
.d..t...... a/
<f+++++++++ a/f1
cL..T...... a/s1 -> f1
cd+++++++++ b/
sent 225 bytes received 108 bytes 222.00 bytes/sec
现在让我们看看目标系统，看看我们收到了什么。在装有 APFS 的 Mac 上运行此程序：
ls -lgR mve # Directory created by rsync from UNIX/Linux
total 0
drwxr-xr-x 4 staff 128 Nov 9 08:25 A
drwxr-xr-x 2 staff 64 Nov 9 08:25 b
mve/A:
total 0
-rw-r--r-- 1 staff 0 Nov 9 08:25 f1
lrwxrwxrwx 1 staff 2 Nov 9 08:25 s1 -> f1
请注意，没有a目录 - 它被视为与相同A。因此，当您在“A”中有一个指向文件的符号链接时a 和a如果您在 中还有一个与 中同名的符号链接，A则会发生冲突。（在 和 中，如果文件大小或时间戳不同，则也会发生冲突A。a）
为了演示您的问题，请返回具有 ext4 文件系统的 UNIX/Linux 系统并再次复制原始文件，注意源文件和目标文件均未发生任何更改：
rsync -iav . bigsurmac:mve # Uh oh, some files need recopying
building file list ... done
cL..T...... A/s1 -> ../a/f1
.d..t...... a/
cL..T...... a/s1 -> f1
sent 165 bytes received 38 bytes 135.33 bytes/sec
total size is 9 speedup is 0.04
您可以看到，尽管没有进行任何更改，但有些项目需要重新复制。这是由于目标上的文件系统不区分大小写造成的，这意味着您不能同时拥有目录a和，因此其中一个目录中的某些文件将始终显示为丢失。此外，如果您拥有和每个文件的名称相同但内容不同，则其中一个相对于其源而言始终是错误的（两个源，一个目标）。AaA
因为问题在于文件系统差异，所以这将影响任何复制实用程序，而不仅仅是。例如，rsync您无法使用 解决问题。scp
结果是您无法可靠地将区分大小写的文件系统树（例如在 ext4 文件系统上找到的）复制到 APFS 文件系统。