[netatalk-ja:0239] Re: Mac OS X serverからのrsyncでのデータコピーで不具合

2013年 7月 25日 (木) 22:54:44 JST

HATです。

Thu, 25 Jul 2013 16:09:10 +0900, Taiki Kimura <taikimura8182 ＠ gmail.com>:
> 昨日より、4TBをCCCにてコピーしていましたが、なんと「デバイスに異常がみつ
> かりました」
> というエラーメッセージがGUIで表示され、コピーに失敗してしまいました。。。

これは、
2.2.0の50個のバグに遭遇したか、
未知のバグに遭遇したか、
の、どちらかでしょう。

前者の場合は対応しません。
後者の場合はこのMLにて検証し、パッチが完成した時点で本家に投げます。
パッチができなかったら、本家に丸投げします。

> CCCでのコピーに失敗したこともあったので、
> さきほど、netatalk-2.2.0-2.el6.x86_64をアンインストールし、
> netatalk-3.0.4にて再構築しました。

3.0.4にて同様の現象が発生したら、たぶん未知のバグでしょうねえ。
そうなったら泥沼モードに突入します。

> 私の環境の10.5.8のMacからlinuxサーバへ-Eオプション付きでrsyncできないですね。
> rsync: on remote machine: --extended-attributes: unknown option
> 
> こういうエラーメッセージがでてrsync失敗します。

これは、AFPを経由せず、rsyncの独自プロトコルで転送を試みたということですか。
だとすると、検証する意味がありません。やるだけ無駄です。
もしコピーに成功したとしても、メタデータの扱い方が異なるので、
netatalkで運用できません。

> なぜか、Finderから手動でコピーしても開けないファイルがあったので、
> xattrコマンドで拡張属性を確認してみました。
> 
> ◆macから確認した結果
> # xattr aaaaaaa.doc
> com.apple.ResourceFork

Mac上のコマンドラインからnetatalkボリュームに移動し、xattrで確認してください。

$ cd /Volumes/CentOSのNetatalkのボリューム名/...
$ xattr aaaaaaa.doc
...
...

この結果がローカルボリュームと一致するかどうかが重要です。
更にメタデータの中身を比較して、一致するかどうかを検証してください。

$ xattr -l aaaaaaa.doc

> ◆linuxから確認した結果
> # getfattr aaaaaaa.doc
> # file: aaaaaaa.doc
> user.org.netatalk.Metadata

クセの強いHFS+のメタデータをLinuxのファイルシステムに保存するには、
色々と面倒くさい無茶をする必要があります。
Netatalk 3.xの場合、FinderInfoとか、Netatalk独自の情報をAppleDouble
フォーマットでuser.org.netatalk.Metadataに保存しています。
これの中身を確認する場合、apple_dumpに-eオプションを付けます。

$ apple_dump -e aaaaaaa.doc

HFS+上のファイルにhogehogeという名前の*本物の*拡張属性があった場合、
Linux上のNetatalkは、user.hogehogeという名前の拡張属性に保存します。

> ※同じフォルダ内に._aaaaaaa.docというファイルがあり、apple_dumpで中を見
> ることができます。

HFS+上のファイルにリソースフォークが付いていた場合、Linux上のnetatalkは
チョーめんどくさい処理をします。
リソースフォークは巨大なので、Linux上の拡張属性に保存できません。
しょーがないので、「._」で始まる隠しファイルを作って、
AppleDoubleフォーマットでファインダ情報とリソースフォークを保存します。

この場合、ファインダ情報がuser.org.netatalk.Metadataと「._FILE」の
両方に保存されるので二重管理になります。気持ち悪いです。
これは、ものすごーーーーーーーく面倒な理由によるものなので、
勘弁してやってもらえませんか。

> MagicNumber: 00051607                                        : AppleDouble

AppleDoubleフォーマットであることを示すマジックナンバーです。

> Version    : 00020000                                        : Version 2

AppleDoubleフォーマットにはバージョン1とバージョン2があり、
ここではバージョン2であることがわかります。
バージョン1は極めて古いので、最近は見かけません。

> Filler     : 4E 65 74 61 74 61 6C 6B 20 20 20 20 20 20 20 20 : Netatalk

Appleが発行した文書において、Fillerは16個の空白文字であると定義されています。
つまり、きちんと仕様を守れば、
"                "
になっていなければなりません。

しかしながら、最近のOS XがAppleDoubleを生成する場合、
"Mac OS X        "
という文字列になってます。
自分のところで定義したフォーマットを尊守してません。
つまり、将来性も考えずにフォーマットを定義しておいて、あとで困ったことに
なったので、フォーマットを無視しているわけです。愚か者のやることです。

Netatalkの場合、ながらくAppleDoubleフォーマットを尊守して16個の空白を
入れていました。
しかし最近になって、OS X側が作るAppleDoubleと、Netatalk側が作るAppleDouble
が競合するという問題が指摘されました。
そこで現在のNetatalkは
"Netatalk        "
という文字列を使うことで区別をして、競合を避けるようにしました。
愚か者のマネをすることにより、問題を回避したわけです。
五十歩百歩です。

> Num. of ent: 0002                                            : 2

格納されているメタデータが2つです。

> Entry ID   : 00000009 : Finder Info
> Offset     : 00000032 : 50
> Length     : 00000020 : 32

格納されているメタデータの一つ目がFinderInfoであり、その中身は50バイト目
以降に書かれており、サイズが32バイトです。

問題となるのは、コレのあとに書かれている2つ目のメタデータです。
それはリソースフォークです。この中身が一致するかどうかが重要です。

-- 
HAT