最近我正在调查二进制文件损坏的原因。 具体来说，我们有一个Android应用程序，本机部分可以在SD卡上读/写二进制文件。 有时，二进制文件会因未知原因而破坏。 我们从不同的用户那里收集了一些这些文件，并发现了一些有趣的事实。
一种主要的forms是，二进制文件的前4096字节被擦除。 当我对这些文件进行hexdump时，前4096个字节都是零。 不超过4096或小于4096，但正好是4096字节。 我认为这不是巧合。 我知道4096字节是一页大小。 但是缺乏经验，我无法弄清楚原因，更重要的是，我不知道如何为其他用户/设备避免这样的事情。
除此之外，在一些二进制文件的中间，还有一些连续的零段，它不应该存在。 如果这不是我们程序的错误，是否有任何可能的原因可能与平台/设备内核有关，或者其他任何设备突然断电？
我希望任何经历过类似情况的人都可以给我一些提示/建议/解决方案等。这让我很困惑。
非常感谢〜
我在一些破坏二进制文件的嵌入式应用程序中有一些相似的经验。 首先，仔细检查你的文件处理(特别是在multithreading环境中)，我可以想象你已经彻底完成了。 然后，尝试同步所有的文字。 Linux内核不会在您命令应用程序写入时写入，而是在刷新到磁盘之前缓冲数据。
希望这可以帮助。
检查你的文件处理通常是我的经验中的问题
‘4096字节文件’奇怪地导致文件损坏，甚至文件系统损坏。
这种损坏是由于ext4文件系统的簇大小等于页面大小。
目前，块的默认大小为4KiB，这是大多数支持MMU的硬件上常用的页面大小。 这是幸运的，因为ext4代码不准备处理块大小超过页面大小的情况。
PS
我正在使用ext4，因为它是基于Linux的操作系统的默认文件系统(包括但不限于Android)
现在了解为什么4KiB文件可能存在危险，原因很容易理解：
文件处理不当：创建，读取，编辑或删除文件的过程可能会损坏文件，并可能与整个文件系统一起破坏文件。 这些“不正当程序”包括非人类行为和事故。 (PS：这不仅限于4KiB文件)
不正确的低级数据处理：不是常见的情况，仍然是可能的。 当内核或用户尝试以低级别编辑文件系统时会发生这种情况。 (您需要进一步调查此案例，因为它应该写在一篇太长的文章中！)
仍然有许多奇怪的方法来破坏数据，我试图保持简短。 其他原因取决于许多因素，因此我在Android设备上提到了该问题的最常见原因。
