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

Taiki Kimura taikimura8182 @ gmail.com
2014年 9月 17日 (水) 10:13:15 JST


HATさん 詳細なご説明、いつもありがとうございます。




とりいそぎとなりますが、ResourceForkというファイルの生成について
当方がお伝えし忘れていたのですが、ResourceForkというファイルは、
当方がいつも使っているMavericksで生成し、
それをNetatalk3.0.4のサーバにafp接続して保存したものとなります。

なので、HATさんのご説明で理解したのですが、

> 添付されたAppleDouble Header fileのFillerが「Netatalk        」ではなく、
> 「Mac OS X        」になっていることから、このファイルを生成したのは、
> Mac OS Xであると断定できます。

この断定が正しいことになります。

また、バックアップのMacminiでlsを@を付けて実行した結果もお送りします。

>> # pwd
>> /Volumes/Drobo_Main/A/_temporary/kimura/hoge

# ls -ltra@
total 64
-rwxrwxrwx@  1 aid-dcc  staff   15 Sep 16 11:13 ResourceFork
com.apple.FinderInfo 32
com.apple.ResourceFork 1338
com.apple.TextEncoding 15
drwxrwxrwx   3 aid-dcc  staff  102 Sep 16 11:41 .
drwxrwxrwx  11 aid-dcc  staff  374 Sep 16 11:46 ..


本日、もう一度ご教示いただいた情報を踏まえて調査、検証し、
その結果をあらためてご連絡するようにします。



2014年9月16日 22:52 HAT <hat @ fa2.so-net.ne.jp>:
> Tue, 16 Sep 2014 12:13:35 +0900, Taiki Kimura <taikimura8182 @ gmail.com>:
>
>> ._ResourceForkをメールに添付してお送りしますが、「._」つきだとMacOSからは
>> みえない仕様であることを理解したので、
>> CentOSから当該ファイルのファイル名を変更し、MacOSから扱えるようにしたので
>> そちらをお送りします。
>
> このファイルをapple_dumpコマンドで調べるとわかりますが、
>
> $ apple_dump ResourceFork
> Dumping "ResourceFork"...
> -------------------------------------------------------------------------------
> 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
>
> このファイルのフォーマットはAppleDoubleであり、
> バージョンは2であり、
> Fillerは「Mac OS X        」であり、
> エントリの数は2です。
>
> Fillerと呼ばれる16バイトの領域は、AppleDouble バージョン1の時代は
> Home File Systemという名称でした。名前のとおり、どのようなファイルシステムを
> 使っているかを格納する領域でした。
> バージョン2では、名称がFillerに変更され、「                」、つまり16個の
> スペースを格納することになりました。ファイルシステムの名前を入れておいても
> 特に役に立たないからだと思います。
> ところが、Mac OS X 10.4では「Mac OS X        」、つまり「Mac OS X」の後ろに
> 8個のスペースを格納するようになりました。つまり自ら策定した規格を違反しています。
>
> Netatalkが作るAppleDouble header fileも長いこと16個のスペースを格納していました。
> しかし、ZIPファイルを展開したときに生成されるAppleDouble header fileがコンフリクト
> する問題が発生したので、Fillerに「Netatalk        」という文字列を格納して、
> どのソフトが生成したか判定できるようにしました。これも規格違反ですが、Appleが
> やっている事と同様なので、堂々と違反しています。
> gitのログをみてください。
> https://github.com/Netatalk/Netatalk/commit/23e45f681099477f57a58740016ed666e8c4d284
> この変更が行われたのは10 Oct 2012なので、Netatalk 3.0.4よりも前です。
> Netatalk 3.0.4が生成したFillerは「Netatalk        」になる筈です。
>
> 添付されたAppleDouble Header fileのFillerが「Netatalk        」ではなく、
> 「Mac OS X        」になっていることから、このファイルを生成したのは、
> Mac OS Xであると断定できます。
> これは異常です。
> 何故AFP/netatalk経由でファイルを生成したのに、このファイルが存在するのか。
> まずこれを確認しなければ、話が進みません。
>
> もしかして、もしかすると、AFPで接続しているつもりになっていますが、実際には
> SMBでsambaに接続していませんか?
>
> あと「Num. of ent: 0002」になっていることから、エントリが2つであることが
> わかります。
> 1つめのエントリはFinder Infoです。Finder Infoは32バイト固定です。
> 前半16バイトはFInfo(昔からあるFinderInfo)であり、オールゼロになっています。
> 後半16バイトはFXInfo(拡張FinderInfo)であり、これもオールゼロになっています。
> 結局Finder Infoの32バイトはオールゼロであり、何も設定されていません。
> その後ろに拡張属性の情報が付いています。
> 「num_attrs  : 0001」になっているので、拡張属性の数は1個です。
> その拡張属性の名前は「com.apple.TextEncoding」であり、内容は「UTF-8;134217984」です。
> 2つめのエントリはResource Forkです。
> 「Length     : 0000011E : 286」になっているので、Resource Forkのサイズは286バイト
> です。
> Resource Forkの内容に「This resource fork intentionally left blank」という文字列
> が見えます。実際にはResource Forkが存在しないので、286バイトのダミーのResource
> Forkを付けているわけです。
>
>> ◆環境情報
>> 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 .
>
> ここで「._ResourceFork」が見える原因は2つ考えられます。
> a) 「._ResourceFork」はFillerが「Mac OS X        」になっているので、Netatalkは
>    それを隠蔽していない。
> b) SMB/Sambaで接続しているので、「._ResourceFork」がそのまま見えている。
>
>> ◆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 .
>
> 「._ResourceFork」が存在している理由を知りたいです。
>
> あと、「.AppleDouble」ディレクトリが存在しているのも異常です。
> このディレクトリはNetatalk 1.xまたはNetatalk 2.xが作るものであり、この中に
> AppleDouble Header fileが存在します。
> Netatalk 3.xはこのディレクトリを発見した場合、その中身を調査し、
> Resource Forkを発見したら「._」で始まるファイルに変換します。
> Resource Forkが存在しなかったら、Finder Infoを拡張属性に変換します。
> 変換後は.AppleDoubleディレクトリの中が空になるので、ディレクトリ自体を削除します。
>
> つまり、Netatalk 3.xで運用している場合、.AppleDoubleディレクトリは存在しない筈
> です。
> にもかかわらず、存在しているのは異常です。
> この現象が発生する理由として、私が把握しているケースは2つです。
> a) .AppleDoubleディレクトリ内に孤立したAppleDouble header fileがある。
>    この場合、ディレクトリ内を空にできないので、ディレクトリが削除できません。
> b) afp.confにて「convert appledouble = no」を設定している。
>    これは自動変換機能を停止する設定ですが、あまりお勧めしません。
>
>> ◆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
>
> よくわかりませんが、異常です。
> あと、Mac側のlsコマンドを使う場合、lオプションと一緒に@オプションを付けて
> ください。拡張属性(FinderInfoやResource Forkも含む)の名前やサイズが確認できます。
>
> --
> HAT


netatalk-ja メーリングリストの案内