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

2014年 9月 29日 (月) 23:49:46 JST

HATです。
Fedora 21 alphaでのnetatalk 3.1.6の問題を発見して、こっちを優先しています。
申し訳ないですが、rsync -E問題に関しては雑なテストしかしていません。

Mon, 29 Sep 2014 15:54:07 +0900, Taiki Kimura <taikimura8182 ＠ gmail.com>:
> HATさん
> 
> おつかれさまです　木村です。
> 
>> 別の作業をしてるので追試験してないのですが、私の勘では、
>> com.apple.FinderInfoアリ、com.apple.ResourceForkナシのファイルであれば、
>> FinderInfoがうまくコピーされないですかね?
> 
> 
> 当方が試したことがHATさんが推察されていることと一致しているのか確証ないのですが、
> 以下に記したような状況でテストしてみたところ、FinderInfoがうまくコピーされました。
> 
> 
> ◆Marvericsで作成したファイルからcom.apple.ResourceForkを削除
> $ ls -ltra@ test_a
> -rw-r--r--@  1 kimura  staff  11  9 29 14:51 test_a
> com.apple.FinderInfo       32
> com.apple.ResourceFork     1338
> com.apple.TextEncoding       15
> 
> $ xattr -d com.apple.ResourceFork test_a
> 
> $ ls -ltra@ test_a
> -rw-r--r--@ 1 kimura  staff  11  9 29 14:52 test_a
> com.apple.FinderInfo 32
> com.apple.TextEncoding 15
> 
> ◆com.apple.ResourceForkを削除したファイルを次の流れでコピー
> 
> ・Marverics → Netatalk3.0.4(拡張属性無効)：finderからコピー
> ・Netatalk3.0.4(拡張属性無効) →
> Macmini：MacminiからNetatalk3.0.4(拡張属性無効)をafpマウントしてrsync -Eでコピー
> ・Macmini → Netatalk3.1.6(拡張属性有効)：MacminiからNetatalk3.1.6(拡張属性有効)をafpマウントしてrsync
> -Eでコピー
> 
> 
> ◆MacminiからNetatalk3.1.6(拡張属性有効)をafpマウントしls -ltra@した結果
> $ ls -ltra@ test_a
> -rwxrwxrwx@ 1 aid-dcc  staff  11 Sep 29 14:52 test_a
> com.apple.FinderInfo 32
> com.apple.TextEncoding 15
> 
> ※com.apple.FinderInfoがコピーされています。
> 
> 
> という結果となりました。
> 
> が、やはり、本日も数回試しましたが、
> Marvericsで作成したファイルからcom.apple.ResourceForkを削除せず、
> そのままの状態(com.apple.FinderInfoあり、com.apple.ResourceForkあり、com.apple.TextEncodingあり）で
> Macminiを経由させてrsync -EでNetatalk3.1.6(拡張属性有効)にコピーすると、
> com.apple.FinderInfoが無いファイルとしてコピーされます。
> 
> 
> 試したのはtxtファイルだけなのですが、
> com.apple.FinderInfoが無くても、ファイル自体は編集したり閲覧したりすることは可能なようです。
> 
> 
> これは、どういった状態なのでしょうか。どのように判断したらよいのでしょうか。。。

私の勘が当たっているような気がします。
私の実験では以下のように表示されていました。
$ /usr/bin/rsync -avE -8 --cache --delete /Users/hat/Desktop/rsync_test/ /Volumes/hat/test
building file list ... done
./
._.DS_Store
ICONandEA.txt
._ICONandEA.txt

これは、OS X上のHFS+からAFP経由でNetatalkに転送する実験です。
ここで、「._ICONandEA.txt」が表示されているのが気持ち悪いと思いませんか?
HFS+上には「._」で始まるファイル名は存在しないのに「._ICONandEA.txt」を
転送するのは、何かおかしいです。

AFPプロトコルには、
・FinderInfoを転送する機能
・ResourceForkを転送する機能
・本物の拡張属性を転送する機能
があります。まあ、アタリマエの機能ですね。
だからこそ、Finderで転送した場合は、これらの機能が実行されて、正常に
転送できていると思われます。

ここで、私の仮定です。
rsync -Eをしたとき、FinderInfo、ResourceFork、本物の拡張属性を転送する
機能を使っていないのではないでしょうか。
OS XのUnix系コマンドは、Mac特有のメタデータをマトモに扱えないのでは?
これらが存在した場合、「._」で始まるファイル名に変換して転送し、
受取側のサーバが、「._」で始まるファイルの中身をFinderInfo、ResourceFork、
本物の拡張属性に戻すことを期待しているのではないでしょうか。

この仮定をもとにした実験。

----------------------------------------------------------------------
実験1: FinderInfoもResourceForkも本物の拡張属性もないファイルを転送
$ /usr/bin/rsync -avE -8 --cache --delete /Users/hat/Desktop/rsync_test/ /Volumes/hat/test
building file list ... done
./
.DS_Store
._.DS_Store
ICONandEA.txt

どれも付いてないファイルを転送する場合は、「._ICONandEA.txt」を転送して
いません。
メタデータがないから、そういうファイルを転送する必要がない。
メタデータがないから、何も問題は発生しない。

----------------------------------------------------------------------
実験2: FinderInfoアリ、ResourceForkナシ、本物の拡張属性ナシを転送
$ /usr/bin/rsync -avE -8 --cache --delete /Users/hat/Desktop/rsync_test/ /Volumes/hat/test
building file list ... done
./
.DS_Store
._.DS_Store
ICONandEA.txt
._ICONandEA.txt

FinderInfoがあるので、「._ICONandEA.txt」を転送している。
FinderInfoは壊れていない。

----------------------------------------------------------------------
実験3: FinderInfoナシ、ResourceForkアリ、本物の拡張属性ナシを転送
$ /usr/bin/rsync -avE -8 --cache --delete /Users/hat/Desktop/rsync_test/ /Volumes/hat/test
building file list ... done
./
.DS_Store
._.DS_Store
ICONandEA.txt
._ICONandEA.txt

ResourceForkがあるので、「._ICONandEA.txt」を転送している。
FinderInfoが最初からないので、問題は発生しない。

----------------------------------------------------------------------
実験4: FinderInfoアリ、ResourceForkナシ、本物の拡張属性アリを転送
$ /usr/bin/rsync -avE -8 --cache --delete /Users/hat/Desktop/rsync_test/ /Volumes/hat/test
building file list ... done
./
.DS_Store
._.DS_Store
ICONandEA.txt
._ICONandEA.txt

FinderInfoと本物の拡張属性があるので、「._ICONandEA.txt」を転送している。
FinderInfoは壊れていない。

----------------------------------------------------------------------
実験5: FinderInfoアリ、ResourceForkアリ、本物の拡張属性ナシを転送
$ /usr/bin/rsync -avE -8 --cache --delete /Users/hat/Desktop/rsync_test/ /Volumes/hat/test
building file list ... done
./
.DS_Store
._.DS_Store
ICONandEA.txt
._ICONandEA.txt

FinderInfoとResourceForkがあるので、「._ICONandEA.txt」を転送している。
FinderInfoが壊れた!!!!!!!

----------------------------------------------------------------------
以上の実験により、FinderInfoが壊れる条件は、
FinderInfoとResourceForkの両方が付いているとき、
だけです。

rsync -Eはファイルに何らかのメタデータが付いているとき「._」で
始まるファイルを転送します。
一方、拡張属性が有効なNetatalk 3.xは、ファイルにResource Forkが
付いている場合のみ「._」で始まるファイル名を作ります。
OX Xのrsync -Eが送ってくる「._」と、Netatalkが自分で作る「._」が
コンフリクトした結果、FinderInfoが壊れるのではないでしょうか。

すなわち、Netatalk 3.xの「仕様」に問題がある。
「仕様上のバグ」っていうんですかねぇ。

この仮説を立証するには、AFPのパケットをダンプする必要がありますが、
この作業はチョーめんどくさいので、今日はパスします。

> →拡張属性を有効にしたNetatalk3.1.6に正式に移行するにあたり、Macminiに保存されているバックアップデータを
> 　rsync -Eでコピーしていってもよい状態なのでしょうか？？？

いまのところ、現状のまま運用すべきですね。
もし「仕様上のバグ」であるならば、仕様変更しなければ解決しません。
仕様変更はかなりの作業量だと思うし、そもそも変更可能なのか???

-- 
HAT