[netatalk-ja:0376] Re: rsync -Eでもコピーされない._ファイルについて
Taiki Kimura
taikimura8182 ＠ gmail.com
2014年 9月 16日 (火) 12:13:35 JST
HATさん 詳細なご説明ありがとうございます。
ご教示いただいた内容をもとに、現環境を今一度確認した結果をメール本文に記載してお伝えします。
(守秘義務が無いディレクトリやファイルでrsyncやdiff -rを実行した結果をお送りします)
Macminiから._ResourceFork自体は見えていないようですが、diff -rの結果としてはメール本文の通りとなっています。
._ResourceForkをメールに添付してお送りしますが、「._」つきだとMacOSからはみえない仕様であることを理解したので、
CentOSから当該ファイルのファイル名を変更し、MacOSから扱えるようにしたのでそちらをお送りします。
◆環境情報
Netatalkボリューム名前：/Volumes/A
Macmini+外付けストレージのボリューム：/Volumes/Drobo_Main/A
※netatalkは、3.0.4です。
◆Netatalk上で管理しているMasterデータをMacminiからみた結果
# pwd
/Volumes/A/_temporary/kimura/hoge
# ls -ltra
total 32
-rwxrwxrwx 1 aid-dcc staff 4096 Sep 16 11:13 ._ResourceFork
-rwxrwxrwx@ 1 aid-dcc staff 15 Sep 16 11:13 ResourceFork
drwxrwxrwx 1 aid-dcc staff 330 Sep 16 11:41 ..
drwxrwxrwx 1 aid-dcc staff 264 Sep 16 11:41 .
◆Netatalk上で管理しているMasterデータをCentOSからみた結果
# pwd
/share/A/_temporary/kimura/hoge
# ls -ltra
合計 20
-rwxrwxrwx 1 kimura Domain Users 4096 9月 16 11:13 2014 ._ResourceFork
-rwxrwxrwx 1 kimura Domain Users 15 9月 16 11:13 2014 ResourceFork
drwxrwxrwx 9 aid-dcc Domain Users 4096 9月 16 11:41 2014 ..
drwxrwsrwx 2 kimura Domain Users 4096 9月 16 11:41 2014 .AppleDouble
drwxrwsrwx 3 kimura Domain Users 4096 9月 16 11:41 2014 .
◆Macmini＋外付けストレージで管理しているバックアップデータ
# /usr/bin/rsync -aEzuv -8 /Volumes/A/_temporary/kimura/hoge/
/Volumes/Drobo_Main/A/_temporary/kimura/hoge/
building file list ... done
./
ResourceFork
._ResourceFork
# pwd
/Volumes/Drobo_Main/A/_temporary/kimura/hoge
# ls -ltra
total 64
-rwxrwxrwx@ 1 aid-dcc staff 15 Sep 16 11:13 ResourceFork
drwxrwxrwx 3 aid-dcc staff 102 Sep 16 11:41 .
drwxrwxrwx 11 aid-dcc staff 374 Sep 16 11:46 ..
# diff -r /Volumes/A/_temporary/kimura/hoge/
/Volumes/Drobo_Main/A/_temporary/kimura/hoge/
Only in /Volumes/A/_temporary/kimura/hoge/: ._ResourceFork
2014年9月13日 1:56 HAT <hat ＠ fa2.so-net.ne.jp>:
> 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
-------------- next part --------------
テキスト形式以外の添付ファイルを保管しました...
ファイル名: ResourceFork
型: application/octet-stream
サイズ: 4096 バイト
説明: 無し
URL: </mailman/archives/netatalk-ja/attachments/20140916/c45fac77/attachment.obj>
netatalk-ja メーリングリストの案内