[netatalk-ja:0389] Re: rsync -Eでもコピーされない._ファイルについて
Taiki Kimura
taikimura8182 ＠ gmail.com
2014年 9月 25日 (木) 15:45:02 JST
HATさん
configの確認と有益な情報のご教示ありがとうございます！
>> そうすると、現状の拡張属性非対応の状態でNetatalk3.xを、
>> Netatalk2.xに似たような動作のままで利用しつづけなければならない、
>> ということになるのでしょうか？？
>
> しばらくはそうしてください。
なるほどー しばらくはこのままで運用するしかないのですね。。。
ただ、できれば、↓こちらのオススメ手順で対応したいと考えているのですが、
（休日出勤は覚悟していますー）
> 私がオススメする手順:
> 1) Mac MiniがNetatalkの内容を完全にコピーできていることを確認する
> 2) Netatalk停止
> 3) Mac Miniを正規サーバとして公開
> 4) Netatalkを最新版にして全部設定やりなおし
> 5) Mac MiniからNetatalkへrsync
> 6) 内容が同じであることを確認。
> 7) 正規サーバをNetatalkに戻す
当方が運用しているNetatalk+Sambaのファイルサーバは、
ファイル数が390万ほどもあるのです。。。（サイズの総計は6.5TB）
>Mac MiniがNetatalkの内容を完全にコピーできていることを確認する
で、試しに4つのファイルで確認してみましたが、
com.apple.TextEncodingとかcom.apple.quarantineとかの拡張属性が確認できるものと、
com.apple.FinderInfoしかないものがあり、それらを1ファイルずつ、チェックしながら
確認するとなると膨大な時間がかかるということがわかりました。
それでもやはり、地道に1ファイルずつ、
com.apple.TextEncodingとかcom.apple.quarantineとかの拡張属性を
netatalk側ではapple_dump、OS X側ではxattr -p で確認していくしか方法はないのでしょうか・・・
ちなみに、ちょっと違う話になりますが、
xlsxを何度か異なるファイルで確認してみたのですが、
xattrで確認してもcom.apple.FinderInfoしかでてこないので。。。
これは正しいでしょうか？？？
以下、xattrとapple_dumpの実行結果サンプルです。
$ xattr c.txt
com.apple.ResourceFork
com.apple.FinderInfo
com.apple.TextEncoding
$ xattr -p com.apple.TextEncoding c.txt
UTF-8;134217984
$ apple_dump ._c.txt
~~~~ 中略 ~~~~
-EA NAME---: 0 1 2 3 4 5 6 7 8 9 A B C D E F : (ASCII)
00000000 : 63 6F 6D 2E 61 70 70 6C 65 2E 54 65 78 74 45 6E : com.apple.TextEn
00000010 : 63 6F 64 69 6E 67 00 : coding.
-EA VALUE--: 0 1 2 3 4 5 6 7 8 9 A B C D E F : (ASCII)
00000000 : 55 54 46 2D 38 3B 31 33 34 32 31 37 39 38 34 : UTF-8;134217984
~~~~ 中略 ~~~~
$ xattr success.png
com.apple.FinderInfo
com.apple.quarantine
$ xattr -p com.apple.quarantine success.png
0002;54223c8c;Preview;
$ apple_dump ._lcd.xlsx
~~~~ 中略 ~~~~
-EA--------:
pad : 0000 : ..
magic : 41545452 : ATTR
debug_tag : 01352A75 : 20261493
total_size : 00000EE2 : 3810
data_start : 00000078 : 120
data_length: 00000000 : 0
reserved[0]: 00000000 : ....
reserved[1]: 00000000 : ....
reserved[2]: 00000000 : ....
flags : 0000 : ..
num_attrs : 0000 : 0
~~~~ 中略 ~~~~
$ xattr lcd.xlsx
com.apple.FinderInfo
$ xattr -p com.apple.FinderInfo lcd.xlsx
58 4C 53 58 58 43 45 4C 00 10 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
$ xattr ogimage.psd
com.apple.ResourceFork
com.apple.FinderInfo
com.apple.metadata:kMDLabel_zya2exypzrhulknkk5enqbj33y
$ xattr -p com.apple.metadata:kMDLabel_zya2exypzrhulknkk5enqbj33y ogimage.psd
62 70 6C 69 73 74 30 30 33 41 B8 D7 E8 A5 0A 7D
BB 08 00 00 00 00 00 00 01 01 00 00 00 00 00 00
00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 11
# apple_dump ._ogimage.psd
._ogimage.psd:
-------------------------------------------------------------------------------
MagicNumber: 00051607 : AppleDouble
Version : 00020000 : Version 2
Filler : 4D 61 63 20 4F 53 20 58 20 20 20 20 20 20 20 20 : Mac OS X
Num. of ent: 0002 : 2
-------------------------------------------------------------------------------
-EA--------:
pad : 0000 : ..
magic : 41545452 : ATTR
debug_tag : 013525C4 : 20260292
total_size : 00000EE2 : 3810
data_start : 000000BC : 188
data_length: 00000032 : 50
reserved[0]: 00000000 : ....
reserved[1]: 00000000 : ....
reserved[2]: 00000000 : ....
flags : 0000 : ..
num_attrs : 0001 : 1
-EA ENTRY--:
offset : 000000BC : 188
length : 00000032 : 50
flags : 0000 : ..
namelen : 37 : 55
-EA NAME---: 0 1 2 3 4 5 6 7 8 9 A B C D E F : (ASCII)
00000000 : 63 6F 6D 2E 61 70 70 6C 65 2E 6D 65 74 61 64 61 : com.apple.metada
00000010 : 74 61 3A 6B 4D 44 4C 61 62 65 6C 5F 7A 79 61 32 : ta:kMDLabel_zya2
00000020 : 65 78 79 70 7A 72 68 75 6C 6B 6E 6B 6B 35 65 6E : exypzrhulknkk5en
00000030 : 71 62 6A 33 33 79 00 : qbj33y.
-EA VALUE--: 0 1 2 3 4 5 6 7 8 9 A B C D E F : (ASCII)
00000000 : 62 70 6C 69 73 74 30 30 33 41 B8 D7 E8 A5 0A 7D : bplist003A.....}
00000010 : BB 08 00 00 00 00 00 00 01 01 00 00 00 00 00 00 : ................
00000020 : 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
00000030 : 00 11 : ..
2014年9月24日 21:06 HAT <hat ＠ fa2.so-net.ne.jp>:
> 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
netatalk-ja メーリングリストの案内