現在運用中の録画システム(WinXP)は、エンコード後にNAS(Linux)へmp4ファイルを自動コピーする仕組みになっている。このコピーが時々失敗する問題について。
理由はWindowsXPとNAS(Linux, samba, VFS, ext3)のファイル名制限の違い。この制限とは以下のようなもの。
・WindowsXPは、Unicode255"文字"まで
・Linuxは(VFS制限が厳しく)、255"bytes"まで。
sambaの設定がunicode(UTF-8だったかな?)になっているとき、日本語ファイル名をそのままコピーするとLinux上では1文字3bytes扱いとなる。
そのため、比較的容易にWindowsで命名可能かつLinux上で255bytes制限を越えるファイルが作れてしまう(日本語のみであれば86文字以上~255文字以内)。このファイルがコピーに失敗することになる。
本録画システムでこのようなファイル名が生成される条件は、EPGでサブタイトルに番組のあらすじが入ってきた場合。今のところこれ以外の条件では発生していない。
しかし、こういうEPGが結構あるのでとりあえず何とかする必要がある。
さて、できればNAS側のファイルシステム側で吸収させたいのだが、どうも芳しい情報が得られなかった。fuse+NTFS-3gなら255bytes壁を越えられる可能性が0ではなさそうだがはっきりしない。VFS自体をどうにかしたいのだが、こちらは全く情報がない。うーん?
しかたないので今回はこのような長いファイル名は余計な情報が入っているものとして、拡張子前を切り捨てることにした。末尾に録画日付・日時が入ってるものは残して、その前を切る。
それをエンコード用のスクリプトに実装してとりあえず暫定対応。
Windowsのこの255文字ファイル名にはいろいろ悩まされる。UDFでもオーバーするから、DVD/BDにやけないとかもしょっちゅう。UDFはまあしかたないにしてもNASではなんとかしたい。解決方法はあるだろうか。
1案としては、Linux上にVMWareを走らせてその上でWindows+NASを立てる。しかし大仰すぎるし、そもそもHDDがホストOS透過して見えるのかどうかわからないし、このためだけにライセンスを消費するのはいやすぎる。
次案としては、Linux側の対応を待つ。VFSの対応が今まで行われていない以上、2.6のうちはかなり薄い気がするけど、いくつか255bytes overを許容するファイルシステムが出てきてるからある程度の時期にExperimentalなオプションとして提供されそうな気はする。
3案としては、Windows NASを立てる。低消費電力じゃないときついけど、ARMでよければすでに5W程度の端末はあるし、次代のWindowsはARMに対応するという。x86でもATOM, Fusionの次とか、nVidia APUあたりはかなり低消費電力になることが期待される。それでNASにする。
なんか大変なとこに触っちゃったなあ。