仅 s3 同步文件夹中已更改文件的最佳方法

如果无法计算 mtime，则没有现成的答案可以同步更改的文件。正如您所指出的，这意味着如果文件的大小没有改变，那么使用“--size-only”标志将导致 aws s3 sync 跳过这些文件。在我看来，有两条基本路径，您使用的解决方案将取决于您的具体需求。

利用 Git

首先，您可以利用文件存储在 git 中的事实来帮助更新修改时间。 git 本身不会存储元数据，维护者认为这样做是个坏主意。我不会支持或反对这一点，但有两种基本方法可以解决这个问题：

您可以将此元数据存储在 git 中。有多种方法可以做到这一点，其中一种是 metastore，它使用与 git 一起安装的工具来存储元数据并在以后应用它。这确实需要向您的 git 存储库的所有用户添加一个工具，这可能会也可能不会被接受。

另一种选择是尝试从 git 中已经存在的元数据重新创建 mtime。例如，git-restore-mtime 通过使用修改文件的最近提交的时间戳来执行此操作。这将需要在运行同步命令之前运行外部工具，但它不应该需要任何其他工作流更改。

使用这些选项中的任何一个都将允许基本的 aws sync 命令工作，因为时间戳从一次运行到另一次运行是一致的。

做自己的事

从根本上说，您希望上传已更改的文件。 aws sync 尝试使用文件大小和修改时间戳来检测更改，但如果您愿意，您可以编写脚本或程序来枚举您要上传的所有文件，并将它们与少量额外元数据一起上传包括诸如 sha256 哈希之类的东西。然后在以后的运行中，您可以使用 list-objects 枚举 S3 中的文件，并依次在每个对象上使用 head-object 以获取元数据以查看哈希值是否已更改。

或者，您可以使用 S3 中每个对象的“etag”，因为它在 list-objects 调用中返回。据我了解，etag 公式没有记录在案，可能会发生变化。也就是说，众所周知，您可以在 Stack Overflow 和其他地方找到 implementations of it。您可以计算本地文件的 etag，然后查看远程文件是否不同并需要更新。这将使您不必在检查更改时对每个对象执行头部对象。