rsync与其他“更简单”的命令（如cp.
我有一个测试设置，涉及 AWS 文件网关以及适当的 NFS 共享和 S3 存储桶。文件网关允许访问 S3 存储桶中的数据，就好像它是任何“正常”NFS 挂载一样。
在后台，S3 正在将旧数据移动到 Glacier，但这些文件在 NFS 挂载中仍然可见，我称之为“稀疏文件”（即元数据存在，但没有实际数据 - 不确定这是否是正确的术语或不是），因此该过程是透明的。我已经使用 CloudWatch 日志设置了带有 lambda 函数的 S3，以便在请求文件但发现文件位于 Glacier 时自动启动 Glacier 恢复（这里有关详细信息，请感兴趣）。
rsync我的问题与其他人之间的行为差异有关cp。
当我尝试将cpNFS 中的文件挂载到另一个位置时，如果该文件位于 glacier 中（即不可读），它几乎会立即返回该文件的 IO 错误，然后退出。对我来说，这是一种理想的行为。
但是，如果我运行rsync -rvhWP它，就好像它实际传输数据一样，它会在目的地创建一个具有正确文件大小等的文件。但它只是随机 1 和 0 的数据。它会在传输结束时rsync: read errors mapping "<FILE PATH>": Input/output error (5)说WARNING: <FILE> failed verification -- update discarded (will try again).它一次又一次地尝试...但那是在将 150GB 垃圾数据传输到目的地之后，这些数据只是留在那里，没有被删除。
为什么要这样做rsync？这是预期的（如果不理想的）行为吗？为什么不cp立即报文件IO错误？rsync有没有办法阻止这种不良rsync行为？
您可能会说“只需使用然后”，这是一个有效的观点，只是提供可跟踪的进度数据cp的情况，而且我认为对于从网络位置传输文件来说更稳健。rsyncrsync