ファイルサーバの改造 |
以下の記述は、ファームウエアバージョン 1.01に基づいています。ファームウエアバージョン 1.3ではWindowsとMacintosh混在環境での文字化けの不具合は改善されていますので、リスクを犯して改造する必要はありません。
現状LANDISKは、WindowsとMacintosh(っていうかsambaとnetatalk）が扱う日本語コードが不整合で文字化けし、我が家のようなWindows/Macintosh混在環境では、使い物にならない状態です。その昔68kMacにNetBSDを入れてサーバとして使っていた時でさえ、そのような問題は無かったのに、ちょっとひどすぎ。 当時はsambaの漢字コードを"CAP"互換にしてリコンパイルすれば、容易に文字化けの問題は解消したのですが、今のSambaはダメなのかな？
調べたところ、smb.conf(/etc/samba.d/smb.conf)で、
| coding system = cap |
ここで指定したcapエンコーディングは、2バイト文字を3バイトで表現するので、ファイル名が最悪1.5倍の長さになってしまう欠点があります。そのため、長いファイル名を多用している場合は、コピーできないファイルがでできますので、Macを使用しない場合は、この指定はしないほうがよいと思います。
Windows, MacOS8,9, MacOS Xのうちファイルサーバと最も相性が悪いのは MacOS Xです。今回の改造を施した後は、Windows, MacOS8,9ではコピーできなかったり、不具合を感じることは皆無になりました。MacOS Xだけはコピーできないファイルが残ります。しかも、コピー中にそういうファイルに出くわすと、無条件でコピーが中断してしまい、しかもどこまでコピーしたのかもわからず、どのファイルが原因でコピーが中断したのかすらわかりません。こんなもんがまともなOSと言えるのでしょうか？MacOS X最低です。
| ファームウエアバージョン 1.3 |
ファームウエアバージョン 1.3では、念願のWindowsとMacintosh混在環境での文字化けの不具合が改善されました。調べてみるとnetatalk側をSJISに対応させることにより、文字化けを無くしているようです。つまり、LANDISKのLinixファイルシステムでは日本語ファイル名はSJISで定義したまま、netatalkが作成する日本語ファイル名もcapではなくSJISに合わせたようです。netatalkは通常、capエンコーディングという独自の方法で２バイト文字をエンコーディングします。これまでcapでエンコードするのではなくEUCでエンコーディングするパッチは出回っていたのですが、SJISエンコーディングに対応したnetatalkははじめて見ました。これはアイオーのオリジナルなんでしょうか。なかなか便利です。
しかし、改善されたとはいっても、あいかわらずファイル名の長さ制限が32バイトのままであり、MacOS Xとのファイルのやり取りでは不具合を生じます。MacOS XとClassic Macのどちらからでもまともに使えるファイルサーバにするには、netatalk-2.0を待たなければなりませんが、2004/6に出回っているnetatalk-2.0-beta2では、不具合も多く、いましばらくかかりそうな気配です。