最近我正在调查二进制文件损坏的原因。 具体来说,我们有一个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设备上提到了该问题的最常见原因。