Android端TF卡文件写入后MD5不符问题排查咨询

先贴出问题中的代码（修正了参数逗号的笔误）：

bool WriteAndVerify(unsigned char* pvData,int dwLength){
    if (!FileVerifyData(pvData,1, dwLength))
    {
        return false;
    }
    if (!fwrite(pvData,1, dwLength,stream))
    {
        return false;
    }
    // 未调用fflush()
}

针对你遇到的Android客户端小概率文件损坏问题（带外置TF卡的华为手机，损坏块为64K/128K，内容疑似其他进程数据），结合代码和场景，可能的原因如下：

• 关于你提到的“其他缓冲区栈溢出覆盖写入数据”
  这个可能性不大。pvData是函数输入参数，要是栈溢出覆盖了这块内存，FileVerifyData校验时就会失败，根本走不到fwrite步骤。就算溢出刚好发生在校验后、写入前，这种时间窗口极小，而且溢出导致的损坏通常是随机乱码，不会是规整的64K/128K块。

• 关于“TF卡物理地址到虚拟地址映射错误”
  有一定可能，但硬件层面的映射错误一般会伴随频繁的IO报错，比如读写失败、系统弹出存储异常提示，不会只小概率出现规整块的数据替换。不过华为对存储驱动可能有定制优化，要是TF卡处于低功耗或繁忙状态，驱动层面可能出现临时的映射错乱，导致其他进程的缓存数据被写入当前文件。

• 最可能的核心原因：未刷新C标准库缓冲区，和Android TF卡IO机制冲突
  fwrite只是把数据写到用户态的缓冲区，并没有真正同步到磁盘。结合Android和华为的存储逻辑：

  1. 系统对外置TF卡会做IO请求合并，当多个进程的IO堆积时，可能出现缓冲区复用错误，把其他进程的缓存数据写到了你当前文件的块位置；
  2. 华为手机对TF卡可能用了64K/128K的聚合写入块，而你代码里的C标准库缓冲区是16K，没及时刷新的话，系统合并写入时会把当前进程未提交的缓存和其他进程的缓存块混在一起写，造成数据污染；
  3. 要是你的应用被后台回收或者CPU调度切换，未刷新的用户态缓冲区可能被系统回收复用，后续写入时就会把其他进程的数据错误填充到当前文件里。

• 补充原因：TF卡文件系统的延迟分配机制
  像FAT32、exFAT这类常用的TF卡文件系统，会用延迟分配——fwrite返回成功只是数据进了缓存，实际磁盘块还没分配。如果其他进程先占用了预期的磁盘块，系统重新分配时就可能出现数据覆盖，而64K/128K刚好是TF卡常见的分配单元大小，这也能解释损坏块的规整性。

内容的提问来源于stack exchange，提问作者sam want