对于使用rclone进行对象的迁移传输，默认的校验机制网上大部分的说法都是——文件大小和修改时间。
但是在我们使用的过程中却发现，无论是本地拷贝到对象存储，还是对象存储到对象存储，文件的最后修改时间都会变成进行传输的时间，这跟网上说的默认校验机制是相互违背的，最后修改时间都变动了，是如何完成传输、如何通过校验的呢？
这一问题，在网上却没人解释的清楚，也没有找到相关的资料。
所以对于此问题进行了深入的研究，终于找到了其校验的方法。
结论是：s3协议传输后不会记录文件的修改时间等信息，也就是说现在所有基于s3的对象存储进行复制传输等操作后都没办法保留修改时间等属性，但是通过rclone进行传输过的文件，会自动将其追加上一条名为“mtime”，值为“自UTC 时间 1970-01-01 00:00:00 以来所经过的秒数”（如1648692422.790367995）的“元数据”，从而达到记录文件修改时间的目的。rclone默认的校验机制就是通过校验源目两端对象元数据中的mtime值是否相等实现的，对象存储控制台上显示的最后修改时间并不一定能代表这个文件真实的最后修改时间。在拥有mtime元数据的对象使用rclone传输至本地后，rclone会依据元数据中mtime记录的时间，将文件的修改时间恢复成mtime中所记录的修改时间，也就是文件原本的修改时间。（个人理解，有问题请指正）
华为云对元数据的解释：元数据（Metadata）为描述对象属性的信息，是一组名称值对，用作对象管理的一部分。
1、为什么说rclone以元数据mtime的值做校验？
1、查看文件修改时间为15:12
2、将文件利用rclone上传至对象存储，可见，最后修改时间变为了传输时间15:18
3、此时，按现有显示结果，原文件的修改时间为15:12，对象存储上的最后修改时间为15:18，不相等，如再次传输此文件，按默认修改时间检验的说法，会因修改时间不同而重传。但再次传输测试日志输出Size and modification time the same，Unchanged skipping。有些蹊跷~
4、本想通过obsutil工具查看对象的修改时间（LastModified）参数，来验证下是否为web控制台显示不准确，但突然发现了元数据中有一个mtime值，mtime在Linux文件系统中表示修改时间的意思。遂豁然开朗。
5、即将相同测试文件上传至阿里oss上，发现二者元数据中mtime值相同，即得出相同文件的mtime值不会因传输时间和目的系统不同而不同，源文件不被修改此值是不会变动的。
date -r 文件名 +%s.%N ##可以查看出文件的修改时间
date -r 文件名 +%F:%T ##可将时间以人类可读的方式显示出来
可以看出，与元数据中的mtime值基本相同。（上次的结果是完全相同的）
q：为什么原始文件的时间后边多了个0？
a：因为rclone默认可以接受在1ns内的误差，点后边表示的是纳秒，可见相差并不到1ns，故可以通过校验。
所以得出结论，rclone采用元数据中mtime值，进行的修改时间一致性校验。
2、为何断定mtime是rclone加上的？
可能存在疑问，mtime是不是本来就存在对象的元数据中，或者其他方式上传的文件也默认带有mtime数据
证明：
1、首先使用了obs官方的工具obsutil，进行本地文件上传至对象存储的测试
由下图可见，并没有mtime数据。
2、web控制台上传文件
由下图可见，并没有mtime数据。
3、rclone上传
由下图可见，含有mtime数据。
3、仅有rclone可以恢复mtime中的修改时间？
是的。
上面的结论中说“在拥有mtime元数据的对象传输至本地后，rclone会依据元数据中mtime记录的时间，将文件的修改时间恢复成mtime中所记录的修改时间，也就是文件原本的修改时间”那用其他方式下载带有mtime数据的文件会恢复文件的修改时间吗？
证明：
1、链接下载，可见下图中的文件是有mtime数据的，将其下载至本地，看修改时间是否正确。
由下图可见，并不是最初的15:12分，而是上传至对象存储时的时间
2、Windows系统中控制台下载，可见修改时间变为下载此文件时的时间。
3、rclone下载测试
由下图可见，修改时间和最初的15:12相同。
4、源端没有mtime数据的文件传输至另一对象存储后，源文件会不会被加上mtime
1、此时此文件在华为obs中，并没有mtime数据
将其传输至了阿里云oss上
源端并没有添加上mtime数据
目的端加上了mtime数据，因对象存储上的修改时间没有精确到纳秒，所以值仅有前边的10位。
