DJI RONIN 4D变0字节恢复案例

RONIN 4D这个产品听起来比较陌生，还是DJI大疆出品。没错，这是大疆进军影视级的重点明星机型。前阵子刚处理过大疆RONIN 4D的修复案例，下边这个案例是和exfat有关的老问题:文件长度变成0字节。

故障存储:希捷18T /MS Exfat文件系统。

故障现象:

图1：变为0字节的素材文件

希捷的18T单盘，做为移动硬盘使用一直用于存放素材，为了在MAC和WIN系统间切换，所以使用了exfat文件系统。某日在查找使用之前一些素材时发现很多文件变成了0字节。使用通用恢复软件扫描无果（有文件名和容量但不能播放）。

故障分析:

由于客户在发现变成0字节后就没有再做过任何操作，所以这是一个典型的EXFAT文件系统导致的问题。关于EXFAT再来啰嗦下（不在码字了直接复制之前的分析，有好奇心的请公众号搜索同类帖子）：

exfat文件系统出错导致文件属性出错

关于exfat之前说过很多次，但是近期使用此文件系统出问题的机率如此频繁，所以我再赘述下。exfat 全称是Extended File Allocation Table File System，扩展FAT文件系统，FAT就是之前FAT32中的“FAT”即文件分配表，这个表研究数据结构的人不算陌生，从字面意思就能看出，exfat并非全新的文件系统。微软开发此文件系统的目的是为了应对FAT32无法管理单个超过4G的文件，也是为了弥补NTFS日志型文件系统在闪存等小型存储设备中的不足（一个是默认的簇大小过小，一个是不断的读写日志对闪存是一种损耗）。

exfat在存储时使用两种方式，对文件进行分类：

无碎片文件，即连续存放的，通过在exfat目录项中记录首簇指针和长度来获取文件的链表。减少文件系统额外的IO时间，这个算是针对FAT32的升级。
存在碎片的文件，即不连续存放的。因为1是一种理想状态，需要各种条件满足才能达到，但是更多情况下是文件不得不以碎片的形式存在（比如经常删除或者使用空间快要达到上限），这种情况下仍然使用FAT32的FAT表进行文件的表链记录。目录项中只记录首簇指针和文件大小，通过首簇指针进行FAT表跳转，很熟悉的味道，和FAT32一毛一样。

这里不讨论exfat的优劣和传输速度，仅仅一点微软开发exfat初衷是为了解决闪存类的文件系统存储问题，为了弥补NTFS的不足，当然不能说exfat就不能用在非闪存上而是其适用最优对象是闪存类小型存储身设备（如SD卡），

很显然大容量的存储不在这个最优对象之内。

另外技术分析当文件长度变为0后，首簇指针也清0，通过文件头获取首簇指针跳转FAT表发现其FAT表链也清0了。也就是目录项->FAT表所有环节通通出错，目前尚不清楚这是个例还是仅在大型存储上存在，因为目前以我的经验至少没有发现在闪存类存在此问题，所以不好下结论，只能以“exfat的文件系统结构不适合管理大型存储“来做总结，在这里我们强烈建议如果您是视频从业者，在存储文件要用到微软文件系统时强烈建议”非闪存类的存储设备慎用exfat文件系统“避免因此导致数据出问题。

通过分析现存的正常的MOV文件可以得出结论，原始文件本身就存在片段化，有很多碎片存在。片段化的文件依靠的目录项中的首簇指针+FAT表中的表链，两者如果全部出问题，那么表链打破，此时通用类恢复软件是无能为力的（因为目录项中文件长度也变成0字节了，所以通过文件系统去恢复是没有任何希望的）。

得出结论就是：在exfat中多数出错的文件是碎片很多的。

故障处理:

此类exfat变0字节的案例处理了很多，也引发了CHS实验室工程师的思考，我们常规的方法是通过使用CHS零壹视频恢复高级版来扫描即可，这种方法极其有效，因为是通过定位视频数据块（音视频帧）来扫描和重组所以识别精确恢复效果极好，但有一个小的缺点就是处理大容量盘时可能时间略长。我们一直在寻找此类问题的快速解决方案，精确的模型能实现精确定位但是带来了时间成本过高。

经过一次次的尝试，通过对损坏情况的仔细分析，提出一种针对exfat清0即可以快速扫描还可以提高质量的算法，这个算法借鉴于当前的云存储模型，通过对故障特征输入让其有一定学习能力我们命名为“CHSFS级算法”。通过几次案例的恢复，此算法可以成功应对一部分exfat变0字节的情况。目前在CHS零壹视频恢复影视版内测程序中增加了这个功能，后期我们会根据情况尽最大努力不断优化算法!

STEP1:运行CHS零壹视频恢复影视版选择18T存储设备，点击右键扫描大类“阿莱影视”(目前影视版暂时没有添加DJI RONIN 4D由于其和阿莱结构相近所以暂选ARRI)，扫描小类选择“mov”,然后点击下方“高级设置”。