我有一段遗留代码，它在调用fstat之前发出对fsync的调用，以确定目标文件的文件大小。（特别是，代码只访问stat结构之外的strongize。）
看过这些文件后，我认为这不是一个必要的电话，但我想听听专家的意见。
在正确实现的文件系统上，发出对fsync或fdatasync的调用不应影响任何后续stat/fstat/lstat调用的结果。它的唯一效果应该是，任何未刷新的写入，以及在fsync的情况下，任何修改的元数据都将提交到永久存储。无论实际数据是否已进入永久存储，stat及其变体都可以很好地处理缓存写入。
也就是说，在您正在研究的代码中是否需要fstat是一个语义问题，取决于如何使用fstat的结果。例如：
-
如果使用它是因为误解
fsync需要调用才能使用stat获取当前元数据，那么您可能可以删除它。 -
如果它被用来写某种检查点数据，那么它并不是完全无关的，尽管调用顺序可能需要颠倒——对于一个不断增长的文件，检查点数据需要指示文件中肯定已经进入永久存储的部分，因此调用
fstat是有意义的，然后调用fsync*，然后写入检查点信息。 -
如果它被用作I/O绑定操作的某种UI进度监视器，那么显示实际提交到磁盘的数据量可能是有意义的。不过，在这种情况下，监视器的精度并不重要，因此调用顺序可能没有那么重要。
那么，在您的案例中，fstat的结果是如何使用的呢？
免责声明：可能存在文件系统实现，例如，网络/分布式文件系统实现中，调用fsync可能会更新文件的本地客户端元数据缓存。在这种情况下，fsync调用确实可以提高代码的可靠性。然而，如果是这样的话，那么您可能会遇到比性能问题更严重的问题。。。