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

Hiroyuki Sato hiroysato @ gmail.com
2013年 7月 24日 (水) 01:45:31 JST


木村さん・HATさん

佐藤です。

ただの思いつきですが、rsyncの代わりにdittoを使ったらいかがでしょうか?
otool -L /usr/bin/ditto
とするとCoreFoundationをリンクしているようなので、Finderと同じことを
コマンドで実現できるかもしれません。

あとは私はつかったことがありませんが、CpMacコマンドもCoreFoundationを
リンクしているようです。

ご参考になれば幸いです。



2013年7月23日 23:21 HAT <hat @ fa2.so-net.ne.jp>:

> HATです。
> 同等の環境がすぐに用意できないので、思いつくことだけ書きます。
>
> > 現在Mac OS X server(10.5.8)で運用しているファイルサーバをLinuxOSへ
> > リプレイスしようとしていますが、Mac OS X serverからrsyncでLinuxOSで
> > 稼働させているNetatlkでの共有ディレクトリに対してデータをコピーすると
> > 不具合が発生してしまうためこちらに投稿させていただきました。
> >
> > 以下に事象を記載いたします。
> >
> > ◆環境
> > リプレイスするサーバのOS:CentOS6.4 64bit
> > netatalk:yumでインストールしたnetatalk-2.2.0-2.el6.x86_64
>
> 2.2.0は怪しいですね。2年前のバージョンです。
> 2.2系の最初のリリースなのでバグが沢山あります。
> Frank Lahmがクビになったりしてバタバタしていたので、なんの検証も行われず
> リリースされたものです。その後の2.2.1以降で大量のbug fixがあります。
>
> Fedora/EL用のRPMは、パッケージャがFilip Kocinaに交代してから全く動きが
> ありません。特にEL用は2.2.0を出してから、ほったらかしになっています。
> http://pkgs.fedoraproject.org/cgit/netatalk.git/
>
> https://bugzilla.redhat.com/buglist.cgi?quicksearch=netatalk&list_id=1142576
> http://koji.fedoraproject.org/koji/packageinfo?packageID=449
>
> > ◆クライアント
> > ファイルサーバを利用するクライアントは、
> > Macクライアントからはafpでのファイル共有とし、
> > Windowsクライアントからはsmbでファイル共有をさせようとしています。
> > (sambaは、samba-3.6.9-151.el6.x86_64です)
>
> 以前にこのMLで話題になっていますが、Netatalk/Samba混在だと排他処理が
> うまくいかないケースがあるので注意してください。
>
> > ◆事象
> > Mac OS X server(10.5.8)には、doroboという外付けHDDをマウントしており、
> > そこに4TBほどのデータがあります。
>
> この外付けHDDのフォーマットは何でしょうか。
> 普通のHFS+と考えていいでしょうか。
> FATだったりすると、ちょっと面倒かもしれません。
>
> > その4TBのデータをrsyncでCentOS6.4 64bitのnetatalk・sambaで共有する
> > ディレクトリにコピーしたところ、コピー完了後のファイルをMacクライアントの
> > Finderから見ようとすると、実態はCentOS6.4 64bitサーバ内に存在しているにも
> > かかわらず、閲覧できるファイルと閲覧できないファイルがある、という事象が
> > 発生しました。
>
> 閲覧できるファイルとできないファイルは具体的に何が違うかを調べる必要が
> あります。
>
> 大抵、根本原因は「Macのファイルシステムはクセが強すぎるから」という
> ことになります。
> ファイル名、メタデータ、CNIDあたりに何か異常がないかを調べるのが
> 一般的です。
> メタデータの調査にはapple_dumpコマンドを使います。
>
> あと、rsyncを使っているのが気になります。
> Finderからの操作とTerminal.appからの操作はナントカレイヤが違うそうです。
> Finderによる操作はCore Foundationなるレイヤが使われるのに対し、
> コマンドラインインターフェースによる操作はUNIXの機能をそのまま使うことに
> なるので、もっと下のレイヤなります。
> OS Xのrsyncとかcpとかtarとかは独自のカスタマイズが行われており、
> それなりにMacのメタデータを扱えますが、完璧だとは思わないでください。
> $ man rsyncしてください。
> -a, -8, -E 等のオプションが気になります。
>
> > 閲覧できない、という事象は、ファイルをダブルクリックで開くと、「ファイルが
> > そんざいしていません」といったようなメッセージがでる事象です。
>
> これの原因は、大抵はroundtrip問題です。
>
> 1. サーバがファイルの情報をクライアントに通知する
> 2. その情報を元に、クライアントがサーバに要求を送る
> 3. クライアントから届いた情報が理解できないので、ファイルがないと返答する
>
> つまり、サーバからクライアントに通知された情報と、クライアントから
> サーバに送った情報に食い違いがあるので、ファイルがないという結果になります。
>
> で、なぜ情報が食い違うのかがキモになります。
> ファイル名が食い違う、メタデータが食い違う、CNIDが食い違う等が考えられます。
>
> > Windowsクライアントからはどのファイルも問題なく閲覧できております。
> > linuxサーバ側のファイルシステムレベルでのeaやaclは有効になっております。
>
> つまり、Windows/Sambaには関係のない何らかのデータに問題があります。
>
> > ◆切り分けのために実施したこと
> > Webを色々調べていたところ、HATさんがコメントして次のような情報がみつかった
> > ため、
> >
> > 「netatalkを使うのなら、CentOSとMac間のコピーはnetatalkのみで行なってくだ
> > さい。」
> >
> > http://ezxnet.com/netatalk/entry2307/
> >
> > 切り分けのため、次のようなことを実施したところ事象解消しました。
> >
> > ・一旦rsyncでCentOS6.4 64bitサーバにコピーしたデータを削除し、Finderから
> > 手動でファイルやフォルダをコピー&ペーストしてみた
>
> つまり、上に書いたように、Finderとコマンドラインではメタデータ等の
> 扱い方が違うということです。
>
> > ◆困っていること
> > 上述の方法で合計4TBのファイルをFinderから手動でコピーするのは少し厳しく、
> > また、差分が出た場合に差分だけを埋めるということもできないため、
> > 他に何かよい方法がないものかと思いこちらに投稿しました。
>
> 移行するファイル群は、リソースフォーク、拡張属性、ファインダ情報等は
> 重要でしょうか。重要ならばNetatalkでキッチリ解決する必要があります。
>
> データフォークだけが重要ならば、転送方法はafpだろうが、smbだろうが、
> ftpだろうが、なんでもいいです。転送後にリソースフォーク、拡張属性、
> ファインダ、CNIDデータベース等を削除すればスッキリするでしょう。
>
> > ちなみに、↓のページを参考にして、
> >
> > http://blog.pc-logon.com/?p=5252
> >
> > Mac OS X server(10.5.8)からLinuxサーバに対してmount_afpし、
> > その後、Mac OS X server(10.5.8)のローカルなディレクトリ同士でのrsyncを
> > 試してみましたが、結果は、Mac OS X server(10.5.8)からLinuxサーバに対して
> > 直接rsyncした場合に発生した時と同じで、実態が存在しているのに閲覧できる
> > ファイルと閲覧できないファイルがある、という事象が発生しました。。。
>
> mount_afpコマンドの利点は、
> マウントポイントを自由に指定できる、スクリプトで自動化できる
> ということだと思います。
> マウント後の動作は通常の方法と同じかもしれません。
>
> > よい方法があれば、ご教示いただけないでしょうか。
>
> 悩んで時間を浪費するなら、Finderで地道にコピーした方が結果的に
> 速いかもしれない...
>
> あと、設定ファイルを見せてください。最も重要です。
> 単に書き間違いというケースもあるし、再現実験を行う場合に必須の情報となり
> ます。
> ログファイルもみてください。CNIDあたりの問題だと、ログがトンデモねえ
> ことになっています。大抵。
>
> --
> HAT
>



-- 
Hiroyuki Sato


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