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

2014年 9月 13日 (土) 01:56:27 JST

HATです。

Netatalkによるサーバを管理しているのであれば、Netatalkがどのように
メタデータを保存しているかを理解しておかないと、色々とマズいです。
まず、「._」で始まるファイルが何かを理解してください。

-----------------------------------------------------------------------

「._」で始まるファイルはAppleDouble header fileといい、Appleが考案した
フォーマットのファイルです。
https://ja.wikipedia.org/wiki/AppleSingle

これはMac特有のメタデータを保存するためのものです。
Mac特有のメータデータには、
    FinderInfo    (32バイト固定)
    Resource Fork (巨大)
    拡張属性      (あまり大きくない)
などがあります。(ほかにもあるけど省略)

FinderInfoとResource Forkは大昔のMac OSからあり、現在のOS Xでは
com.apple.FinderInfoとcom.apple.ResourceForkという名前の拡張属性として
扱うことができますが、これらは本当の拡張属性ではありません。
見かけ上、拡張属性として扱いやすくしているだけです。

本物の拡張属性は最近のMac OS Xで追加されたものです。

OS Xの場合、HFS+上にファイルを作る場合は「._」で始まるファイルは作られ
ません。HFS+はMac特有のメタデータを保存できるので、あたりまえです。
しかしながら、それ以外のファイルシステムをOS X上にマウントした場合は、
Mac特有のメタデータの保存場所がないので「._」で始まるファイルを作って
そこに保存します。
例えば、OS XにFATフォーマットのUSBメモリを接続してファイルを保存すると
「._」で始まるファイルが作られます。
また、代替データストリームに対応しないように設定されたsambaに接続した場合も
「._」で始まるファイルが作られます。

Linux上のNetatalk 3.xの場合、FinderInfoと本物の拡張属性はサイズが
小さいので、Linux側の拡張属性に保存できます。
具体的には、FinderInfoはuser.org.netatalk.Metadataという名前の拡張属性
の中にAppleDoubleフォーマットで保存されます。
ABCという名前の本物の拡張属性はuser.ABCという名前の拡張属性にそのまんま
保存されます。
問題はResource Forkです。これはサイズが巨大なのでLinuxの拡張属性に保存
できません。そこでNetatalkは「._」で始まるファイルを作ってその中に保存
します。つまり、Linux上に「._」で始まるファイルがあった場合、Resource 
Forkが付いている証拠になります。
Netatalkはクライアント側に「._」で始まるファイルを*見せません*。
Resource Forkがあるように見せます。

-----------------------------------------------------------------------

現在のOS Xでファイルに「タグ」を付けると、
    FinderInfo内のcolor属性
    本物の拡張属性
の二ヶ所に保存されます。
FinderInfoのcolor属性は、古いMac OS Xの「ラベル」との互換性のために
あります。

OS Xでファイルにカスタムアイコンを付けると、これはリソースフォークに
保存されます。

従って、OS X上のファイルに「タグ」と「カスタムアイコン」を付けると、
FinderInfo、Resource Fork、本物の拡張属性の3つができます。
そういうファイルを作って動作確認してください。

Netatalkにオマケで付いてくるapple_dumpコマンドを使うと、AppleDoubleの
内容を確認することができます。

OS XがUSBメモリやsambaに保存したファイルをapple_dumpで確認してください。
そしてFinderInfo、Resource Fork、拡張属性がどのように保存されているか
をチェックしてください。

次にAFP経由でNetatalkが作ったファイルをapple_dumpで確認してください。
OS Xが直接USBメモリに作ったものとは微妙な違いがあります。

-----------------------------------------------------------------------

> そこで、とりあえずの案として次のように、Macmini(OS X10.8.5)からNetatalk
> ボリュームをafpマウントした状態で、
> 
> $ diff -r hoge(Netatalk上のフォルダ)  hoge（Macmini OS X10.8.5上のフォルダ）
> 
> とディレクトリの比較を行ってみました。
> 
> すると、「._fuga.png」といったような名前のリソースフォーク？？が、
> なぜか、Netatalk上のフォルダ内にだけ存在しMacmini(OS X10.8.5)上の
> フォルダには存在していない、ということがdiff -rの結果としてでてきました。

ここが何かおかしいです。
たとえLinux上に「._fuga.png」というファイルがあったとしても、AFP経由で
Macからみた場合、そのファイルは隠蔽されて見えない筈です。
Mac上のdiff -rでそれが発見できたのは異常です。
本来ならば、その内容はFinderInfo、Resource Fork、拡張属性としてMac側に
見せる筈です。
MacのHFS+上に「._fuga.png」が存在しないのはアタリマエです。そんなファイルを
作る必要はありません。HFS+に保存できるのですから。

その「._fuga.png」に守秘義務がないのであれば、メールに添付して送ってください。
私が解析します。
守秘義務があるのであれば、apple_dumpコマンドを使って自力で解析し、どこに異常
があるか発見してください。

> fuga.pngの実態は、正常にMacmini(OS X10.8.5)上のフォルダに保存(バックアップ)
> されていて閲覧編集など問題無いのですが、
> この当方の環境で発生しているNetatalk上のフォルダ内にだけ「._fuga.png」
> が存在しているという状態は正しいのでしょうか？

私に想像では、そのファイルにはResource Fork付いており、「._fuga.png」が
存在するのは正常です。
しかしながら、Macから「._fuga.png」が見えるのは異常です。

> なんとなく、当方の浅はかな知識では、Macmini(OS X10.8.5)から
> CentOS+Netatalkのボリュームをafpマウントし、
> その状態でrsync -E すれば、「._」のようなOSX特有のファイル？拡張属性？
> などは全て漏れなく同期される、
> と理解していたのですが、それは違うのでしょうか？

はい。その筈です。

> また、仮に「._」の無いMacmini(OS X10.8.5)上のバックアップデータをそっくり
> そのまま、
> rsync -Eで新しいCentOS+Netatalkのボリュームなどへ同期したとします。
> 
> この場合、MacOSのクライアントPCから新しいCentOS+Netatalkへafp接続し、
> 正常なファイルとして扱うことはできるのでしょうか？

それができないとしたら、Netatalkの存在意義がないですよね。
NetatalkはMacのファイルサーバとして設計されているので、Macのファイルを
正常に扱えなかったとしたら、使い物になりません。
もしそうならば、Netatalkを捨てて別のファイルサーバを検討する必要があります。

-- 
HAT