我正在考虑应用程序在程序或操作系统崩溃后检测部分写入记录的方法。由于记录只是附加到文件（从不覆盖），因此在写入时崩溃是否保证产生的文件大小应该比它应该短？即使文件是以读写模式而不是追加模式打开，只要写入总是在文件的末尾，这是否可以保证？这将大大简化崩溃恢复，因为将最后一条记录的预期大小和位置与实际文件大小进行比较就足以检测到部分写入。
我知道随机访问写入可以由文件系统重新排序，但我无法找到有关在追加时是否会发生这种情况的信息。我想无序追加会要求文件系统在（稀疏）文件的尾部创建一个“洞”，在空洞之外写入块，然后在两者之间填充块，但我希望这种方法效率很低，以至于没有人会以这种方式实现文件系统。
我想另一个问题可能是在将新块附加到文件之前更新目录条目的文件大小字段的文件系统，并且操作系统在两者之间崩溃。这在实践中是否会发生？ （也许是ext4？）是否有快速检测方法？ （当尝试根据文件大小读取应该存在的未写入块时会发生什么？）
还有什么其他的东西，例如磁盘/闪存驱动器执行的写重新排序，会妨碍使用文件大小来检测部分追加吗？我不希望在我的应用程序中能够弥补这种驱动技巧，但是了解它会很好。
答案 0 :(得分：2)
如果您确定永远不会丢失记录，则需要为您的文件提供一致的日记或事务系统。
除非您设置O_DIRECT [您可能不想这样做]，否则绝对不能保证写入已经完成，或者您使用标记来表示#t;这已完全提交＆＃34; ，仅在文件关闭时写入。您可以在主文件中执行此操作，或者，例如，具有在外部记录＆＃34;最后写入记录＆＃34;的文件。如果你打开＆amp;关闭该文件，只要APP崩溃就应该是安全的 - 如果操作系统崩溃[或以其他方式突然停止 - 例如所有的赌注都关闭了。停电，磁盘未插入等等。
写入重新排序和写入缓存是/可以在所有级别完成 - C库，操作系统，文件系统模块和硬盘/控制器本身都可以重新排序写入。