[netatalk-ja:0388] Re: rsync -Eでもコピーされない._ファイルについて

[HAT]

HATです。

>> 実運用しているサーバのafp.confを見せてください。
> 
> 添付しました。
> ディレクトリ名など一部情報を当たり障りないものに変更しています。

[Global]セクションが2回登場してますが、大丈夫かなこれは。

unix charset = LOCALE
Netatalk 2ではLOCALEがデフォルトでしたが、Netatalk 3では私の考えでUTF8に
変更しました。
通常、CentOSのLOCALEはja_JP.UTF-8とかen_US.UTF-8になっていますが、
スーパユーザが個人的趣味でLANG=CとかLANG=ja_JP.EUC-JPで作業している場合が
あります。
このときNetatalkをコマンドラインから再起動すると、LOCALEが違うので
異常動作します。
このあたりのパラメータはデフォルトが吉です。

あっちこっちのページをググって、載っていたパラメータを全部並べる人が
いますが、意味を理解してから使って欲しいです。

>> サーバ側のファイルシステムが拡張属性に対応していない場合、
>> netatalk 3.xはnetatalk 2.xに似た動作をします。
>> すなわち.AppleDoubleディレクトリを作り、その中にAppleDouble Header fileを
>> 作ります。
>> このAppleDouble Header fileの中にFinder InfoとResource Forkが格納されます。
>>
>> そちらのサーバの場合、Netatalkが*クライアント側*の拡張属性に対応していない
>> 状態になっているようです。
>> この場合、OS Xは拡張属性を保存する場所がないので、「._」で始まる
>> AppleDouble Header fileを作り、その中に保存します。
>> 既にみている通り、Finder InfoはオールゼロでResource Forkはダミーであり、
>> 拡張属性が保存されています。
>>
>> つまり、Finder InfoもResource Forkも拡張属性も保存されている可能性が
>> 高いです。
>> rsyncでnetatalkからOS Xにコピーしたとき、「._」で始まるファイルの中に
>> 保存されている拡張属性が、HFS+上では本物の拡張属性になります。
>> したがって、「._」で始まるファイルはHFS+上に存在しなくて問題ありません。
> 
> なるほど。そういうことなんですね。
> 
>> 正しくコピーできているか確認するには、
>> netatalk側ではapple_dump、OS X側ではxattr -p を使ってください。
>> これらを比較して内容が同じであれば正しくコピーできています。
> 
> 
> OS Xから試しに実行してみましたが、$ xattr -p dev_basicだと何も表示され
> ないファイルが、
> $ xattr -l dev_basicだと、apple_dumpと似たような情報がコンソールに出力
> されました。

マニュアルを読んでから使ってください。

$ man xattr
     xattr [-lrsvx] file ...
     xattr -p [-lrsvx] attr_name file ...
     xattr -w [-rsx] attr_name attr_value file ...
     xattr -d [-rsv] attr_name file ...
     xattr -c [-rsv] file ...
     xattr -h | --help

-pの後ろには拡張属性名が必要です。

> $ xattr -l dev_basic
> com.apple.FinderInfo:
> 00000000  54 45 58 54 4D 4D 4B 45 00 00 00 00 00 00 00 00  |TEXTMMKE........|
> 00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
> 00000020
> com.apple.ResourceFork:
> 00000000  00 00 01 00 00 00 05 08 00 00 04 08 00 00 00 32  |...............2|
> 00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
> 
> 省略しましたがこんな感じのデータです。

com.apple.FinderInfoやcom.apple.ResourceForkの他に、本物の拡張属性、
例えばcom.apple.TextEncoding等があるので、このあたりを比較してください。

>> 色々と設定を変えてテストしているようですが、実運用しているサーバの
>> 設定は変更しないでください。
>> Netatalk 2からNetatalk 3への自動変換はある程度対応していますが、
>> 設定変更の場合は自動変換できません。
>>
>> サーバ側のファイルシステムを拡張属性非対応から対応に変更すると、
>> メタデータの保存方法が変わってしまい、うまく変換できません。
>> 今回の場合、「._」で始まるファイルの中の拡張属性が変換できず喪失すると
>> 思います。
> 
> そうすると、現状の拡張属性非対応の状態でNetatalk3.xを、
> Netatalk2.xに似たような動作のままで利用しつづけなければならない、
> ということになるのでしょうか？？

しばらくはそうしてください。

> 素人発想として、どこかで、CentOS側で拡張属性を有効にし、
> Netatalk3.xのデフォルトの動作で利用したほうがよいのでは？？
> と思っているのですが、それはできない、ということなのでしょうか？

はい。オススメは、
1) サーバ側のファイルシステムで拡張属性を使えるようにする。
2) afp.confで余計な設定をしない。
の2点です。

ただし、これは初期設定の話です。
一度運用開始したら、そうそう抜け出せません。ヤクザと一緒です。
これはNetatalkに限った話でなく、Sambaだって一緒です。
Sambaも代替データストリーム等のメタデータの保存方法の設定がありますが、
これを途中で変更するとメタデータを喪失します。

しかしながら、将来性を考えるならば、心機一転で拡張属性を有効にしたほうが
いいと思います。いつかはSambaとNetatalkの保存方法が統一されます。
Netatalk側で妙な方法になっているとすれば、Sambaのsmb.confの設定で
苦しむでしょう。
更に将来にはNetatalkを捨てる日がくるかもしれません。

私がオススメする手順:
1) Mac MiniがNetatalkの内容を完全にコピーできていることを確認する
2) Netatalk停止
3) Mac Miniを正規サーバとして公開
4) Netatalkを最新版にして全部設定やりなおし
5) Mac MiniからNetatalkへrsync
6) 内容が同じであることを確認。
7) 正規サーバをNetatalkに戻す

こういう作業は丸一日かかると思われるので、サーバ停止して全ユーザの恨みを
買うか、もしくは休日出勤する覚悟が必要です。

Netatalk 3.0.4リリース後、色々とbug fixされているし、3.0系はメンテが
止まっているので3.1系の最新版をオススメします。
3.1系も色々問題があってバタバタしてましたが、これはSpotlight関係の
問題です。CentOS 6はSpotlightが使えないので関係ない話です。

>> また、「appledouble =」や「ea =」も変更しないでください。
>> これらのパラメータはデフォルトで最良な状態になるように設計されているので、
>> 使わないのが一番ですが、もし既に設定しているなら変更しないでください。
> 
> 問題のサーバでは、appledoubleは指定しておらず、eaはautoにしていまして、
> それはそのままで変更していません。

ea = autoはデフォルトなので、そもそも設定する必要がないですよね。

-- 
HAT