【2021年 exFATを改めて検証】その4「それでもexFATをオススメしない理由」
今までの再検証記事で、exFATはだいぶマシになってきたことをお知らせしました。
しかし、それでも私は「exFATをオススメしません」
何故そこまで頑なにexFATを薦めないのか？をまとめます。
1. アプリケーション側のテストが放置されがち
exFATは「OSのデータが置かれるファイルシステムではなく、テスト不十分になりがちです」
結果として、各社のアプリケーション上で
「exFATで読み書きしたデータだけ問題が発生する」
という不幸な事が発生します。具体的に並べていきます。
Adobe PremiereにおいてexFAT上でだけ特定のコーデックの再生に問題が発生したことがあります。（13.1で既に修正済み)
ResolveではexFATにDBファイルを置けない（置くな）
社内のトラブル事例としてはmacOS10.13において
「exFATのQT(2時間越えの長尺に限る)だけOS付属のQuickTimePlayerで再生に異常が発生」(macOS10.15以降で解消済)
なお、私自身の個人的経験としてはRapidCopyでexFATに大きいデータ(1MB以上)を書きこんだあと、ベリファイのためにデータを引っ張りだそうとするとリターンしてくるデータが何故か壊れており、ベリファイ失敗になってしまうというなかなか衝撃的な経験があります。
（デバイスドライバ依存でないこと、fsync()忘れなどでないことは確認済）
原因不明なので、RapidCopyではIOサイズを1MBに強制指定してます。
(本当はファイルシステムによっては大きい値を指定したいんですが)
2. 内部仕様が公開されたところで、過去の各社の勝手実装exFATは修正されない
2019年にMSはexFATの実装を公開したわけですが、それまでの各社の実装が「正しい」のかどうかは誰にもわかりません。
つい最近Linux界隈で話題にもなりましたが、Linuxでは「正しい」実装をした結果「正しくない」実装を行なっていた某カメラメーカーのexFATが読めないという問題が発生しました。
これは当時のMSとexFATに関してライセンスを受けてないせいで発生した可能性が高いですが、これが厄介なのはexFATの正式なライセンスを受けているものなのかどうかは外部からはわからない*1ところです。
カメラのマニュアルには「メディアをフォーマットする場合はカメラ本体で行なってください」と書いてあったりしますが、自分以外のexFAT実装を信用するなという開発者からのメッセージなわけです。
*1：過去のニュースリリースなどでわかる場合もあります
3. ジャーナリング機構がない
ジャーナリング処理が無いおかげでCPUパワーのないカメラやレコーダにexFATの実装ができるわけですが
・不正アンマウント時のファイルシステムチェックに時間がかかること
・ファイルシステム修復の際にファイルが破損する可能性
・急な電源断の際にファイルシステム全体が読み込めなくなるリスク
この辺は気になるところです。
今回の再評価実験の結果として、USBメモリやちょっとした個人的なデータの受け渡し程度であれば大丈夫かな？という気持ちになりましたが、
「製作物、納品物の受け渡しやマスターデータの保管先としては不適切であり、推奨できません」
という結論を覆すことはないでしょう。
ちょっと良くなってそうなのはわかったけど、繰り返します。
「(トラブりたくないなら)exFAT、ダメ。」