[netatalk-ja:0390] Re: rsync -Eでもコピーされない._ファイルについて
HAT
hat ＠ fa2.so-net.ne.jp
2014年 9月 26日 (金) 01:36:46 JST
ちょっと話を整理します。
---------------------------------------------------------------------
Finder Infoは大昔のMac OS(当時はMac OSじゃなくてsystemと呼んだ)から
存在しており、全ての*ファイルとディレクトリ*に必ず存在します。
サイズは32バイト固定です。
Fork (Data ForkとResource Fork)も大昔のMac OSから存在しており、
全ての*ファイル*に必ず存在します。*ディレクトリ*には存在しません。
サイズは可変長です。
これらはMacにとって重要なもので、喪失するとエラいことになります。
現在のOS Xでは、Finder Infoはcom.apple.FinderInfoという名前の
仮想的な拡張属性として扱うことができます。
ただし、32バイトすべてがゼロの場合、拡張属性com.apple.FinderInfoが存在
しないという扱いになります。
Resource Forkはcom.apple.ResourceForkという名前の仮想的な拡張属性として
扱うことができます。
ただし、Resource Forkのサイズがゼロの場合、拡張属性com.apple.ResourceForkが
存在しないという扱いになります。
xattrコマンドで拡張属性com.apple.FinderInfoが見つからなかった場合、
Finder Infoの中身がオールゼロだったということになります。
xattrコマンドで拡張属性com.apple.ResourceForkが見つからなかった場合、
Resource Forkのサイズがゼロだったということになります。
*本物の*拡張属性は、Mac OS Xの途中のバージョンで導入された若造です。
だから、あんまり重要な情報は含まれていません。
これを喪失すると、ちょっとしたトラブルは発生しますが、致命的では
ありません。ユーザがイライラする可能性はあります。
---------------------------------------------------------------------
そちらの現在の環境、すなわち
・Linuxファイルシステムの拡張属性が無効
・クライアントからみたAFP上の拡張属性がサポートされない
という状況においては、
abc.txtというファイルがあった場合、
Finder Info
-> .AppleDouble/abc.txtの中にNetatalkが保存
Resource Fork
-> .AppleDouble/abc.txtの中にNetatalkが保存
本物の拡張属性com.apple.hoge
-> ._abc.txtの中にOS Xが保存
ということになります。
ばっちり設定した環境、すなわち
・Linuxファイルシステムの拡張属性が有効
・afp.confで余計な設定をしない
という状況においては、
abc.txtというファイルがあった場合、
Finder Info
-> abc.txtの拡張属性user.org.netatalk.Metadataの中にNetatalkが保存
Resource Fork
-> ._abc.txtにNetatalkが保存
本物の拡張属性com.apple.hoge
-> abc.txtの拡張属性user.com.apple.hogeにNetatalkが保存
ということになります。
---------------------------------------------------------------------
では、Linuxファイルシステムの拡張属性を無効から有効に突然変更すると、
どうなるか???
Netatalkが自動コンバートしてくれます。
Finder Info
.AppleDouble/abc.txt -> abc.txtの拡張属性user.org.netatalk.Metadata
Resource Fork
.AppleDouble/abc.txt -> ._abc.txt
本物の拡張属性com.apple.hoge
abc.txtの拡張属性user.com.apple.hoge -> 多分コンバートされない
つまり、大事な情報であるFinder InfoとResource Forkは大丈夫ですが、
つまんねえ情報しか入っていない本物の拡張属性が見えなくなります。
---------------------------------------------------------------------
>> 私がオススメする手順:
>> 1) Mac MiniがNetatalkの内容を完全にコピーできていることを確認する
>> 2) Netatalk停止
>> 3) Mac Miniを正規サーバとして公開
>> 4) Netatalkを最新版にして全部設定やりなおし
>> 5) Mac MiniからNetatalkへrsync
>> 6) 内容が同じであることを確認。
>> 7) 正規サーバをNetatalkに戻す
>
> 当方が運用しているNetatalk+Sambaのファイルサーバは、
> ファイル数が390万ほどもあるのです。。。（サイズの総計は6.5TB）
いきなりLinux側の拡張属性を有効にしても、Finder InfoとResource Forkは
維持されるでしょう。
本物の拡張属性は消えます。
したがって、Mac MiniからNetatalkへrsync -Eした場合、
多くのファイルは転送されません。
本物の拡張属性が付いているファイルだけが転送されます。
本物の拡張属性が付いているファイルは少ないでしょう。
そして本物の拡張属性はサイズが小さいです。一個あたり最大3802バイトです。
したがって、転送量は小さいです。
>>Mac MiniがNetatalkの内容を完全にコピーできていることを確認する
既に原因は判明しているので、たくさんチェックする必要はありません。
まず、OS X上で、
Finder Infoと、
Resource Forkと、
本物の拡張属性が、
付いているファイルを用意してください、
そのファイルをFinderを使って、OS XからNetatalkへコピーしてください。
それをrsync -EでMac Miniにバックアップしてください。
このファイルの
Finder Infoと、
Resource Forkと、
本物の拡張属性が、
同一ならば、ちゃんとバックアップできています。
これを確認してください。
> で、試しに4つのファイルで確認してみましたが、
> com.apple.TextEncodingとかcom.apple.quarantineとかの拡張属性が確認できるものと
com.apple.TextEncodingは、テキストファイルの文字コードを保存しています。
UTF-8;134217984という値は、文字コードがUTF-8であるという意味です。
現在のMacのテキストエディタは大抵文字コードを自動判定します。
したがって、この拡張属性が喪失してもユーザにはバレないと思います。
com.apple.quarantineは、危険性のあるファイルに自動的につきます。
例えば、インターネットからダウンロードしたファイルに付きます。
そのファイルを開こうとしたとき、「開いてもいいか?」という確認のウインドウが
開きます。OKボタンを押すと、com.apple.quarantineが削除されます。
したがって、この拡張属性が喪失してもユーザにはバレないと思います。
> com.apple.FinderInfoしかないものがあり、それらを1ファイルずつ、チェックしながら
> 確認するとなると膨大な時間がかかるということがわかりました。
全部確認する必要はないです。
> それでもやはり、地道に1ファイルずつ、
> com.apple.TextEncodingとかcom.apple.quarantineとかの拡張属性を
> netatalk側ではapple_dump、OS X側ではxattr -p で確認していくしか方法はないのでしょうか・・・
この2つは喪失してもバレません。
> ちなみに、ちょっと違う話になりますが、
> xlsxを何度か異なるファイルで確認してみたのですが、
> xattrで確認してもcom.apple.FinderInfoしかでてこないので。。。
> これは正しいでしょうか？？？
xlsxは本来はWindows用のフォーマットです。
WindowsにはResource Forkという概念がないので、付いてなくても珍しくないです。
また、Windowsは、本物の拡張属性はほとんど使いません。付いてないのが普通です。
> 以下、xattrとapple_dumpの実行結果サンプルです。
> $ xattr c.txt
> com.apple.ResourceFork
> com.apple.FinderInfo
> com.apple.TextEncoding
> $ xattr -p com.apple.TextEncoding c.txt
> UTF-8;134217984
>
> $ apple_dump ._c.txt
> ~~~~ 中略 ~~~~
> -EA NAME---: 0 1 2 3 4 5 6 7 8 9 A B C D E F : (ASCII)
> 00000000 : 63 6F 6D 2E 61 70 70 6C 65 2E 54 65 78 74 45 6E : com.apple.TextEn
> 00000010 : 63 6F 64 69 6E 67 00 : coding.
> -EA VALUE--: 0 1 2 3 4 5 6 7 8 9 A B C D E F : (ASCII)
> 00000000 : 55 54 46 2D 38 3B 31 33 34 32 31 37 39 38 34 : UTF-8;134217984
これが消えてもバレません。
> $ xattr success.png
> com.apple.FinderInfo
> com.apple.quarantine
> $ xattr -p com.apple.quarantine success.png
> 0002;54223c8c;Preview;
com.apple.quarantineが消えてもバレません。
com.apple.FinderInfoの中身はキッチリ確認してください。
> $ apple_dump ._lcd.xlsx
> ~~~~ 中略 ~~~~
> -EA--------:
> pad : 0000 : ..
> magic : 41545452 : ATTR
> debug_tag : 01352A75 : 20261493
> total_size : 00000EE2 : 3810
> data_start : 00000078 : 120
> data_length: 00000000 : 0
> reserved[0]: 00000000 : ....
> reserved[1]: 00000000 : ....
> reserved[2]: 00000000 : ....
> flags : 0000 : ..
> num_attrs : 0000 : 0
> ~~~~ 中略 ~~~~
>
> $ xattr lcd.xlsx
> com.apple.FinderInfo
> $ xattr -p com.apple.FinderInfo lcd.xlsx
> 58 4C 53 58 58 43 45 4C 00 10 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Finder Infoの最初4バイトはTypeといい、ファイルのフォーマットを意味します。
「58 4C 53 58」をASCIIコードに変換すると「XLSX」です。
つまり、xlsxフォーマットであることを意味しています。
次の4バイトは、Creatorといい、そのファイルを作成したソフトを意味します。
「58 43 45 4C」をASCIIコードに変化すると、「XCEL」です、
つまり、エクセルで作成したファイルです。
そのあとの2バイトは、ビット単位で様々なフラグが入っています。
その内容は、以下のとおり。
isAlias 1bit
Invisible 1bit
hasBundle 1bit
nameLocked 1bit
Stationery 1bit
CustomIcon 1bit
Reserved 1bit
Inited 1bit
NoINITS 1bit
Shared 1bit
SwitchLaunc 1bit
Hidden Ext 1bit
color 3bit
isOnDesk 1bit
今回の場合、「00 10」なので、「Hidden Ext」のフラグが立っています。
つまり、「拡張子を隠す」というフラグです。
そんなもんを隠して何が楽しいのかは知りません。
> $ xattr ogimage.psd
> com.apple.ResourceFork
> com.apple.FinderInfo
> com.apple.metadata:kMDLabel_zya2exypzrhulknkk5enqbj33y
>
> $ xattr -p com.apple.metadata:kMDLabel_zya2exypzrhulknkk5enqbj33y ogimage.psd
> 62 70 6C 69 73 74 30 30 33 41 B8 D7 E8 A5 0A 7D
> BB 08 00 00 00 00 00 00 01 01 00 00 00 00 00 00
> 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 11
ASCIIに変換すると、bplist003A云々ってことですね。よく知らないです。
> # apple_dump ._ogimage.psd
> ._ogimage.psd:
>
> -------------------------------------------------------------------------------
> 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
>
> -------------------------------------------------------------------------------
>
> -EA--------:
> pad : 0000 : ..
> magic : 41545452 : ATTR
> debug_tag : 013525C4 : 20260292
> total_size : 00000EE2 : 3810
> data_start : 000000BC : 188
> data_length: 00000032 : 50
> reserved[0]: 00000000 : ....
> reserved[1]: 00000000 : ....
> reserved[2]: 00000000 : ....
> flags : 0000 : ..
> num_attrs : 0001 : 1
> -EA ENTRY--:
> offset : 000000BC : 188
> length : 00000032 : 50
> flags : 0000 : ..
> namelen : 37 : 55
> -EA NAME---: 0 1 2 3 4 5 6 7 8 9 A B C D E F : (ASCII)
> 00000000 : 63 6F 6D 2E 61 70 70 6C 65 2E 6D 65 74 61 64 61 : com.apple.metada
> 00000010 : 74 61 3A 6B 4D 44 4C 61 62 65 6C 5F 7A 79 61 32 : ta:kMDLabel_zya2
> 00000020 : 65 78 79 70 7A 72 68 75 6C 6B 6E 6B 6B 35 65 6E : exypzrhulknkk5en
> 00000030 : 71 62 6A 33 33 79 00 : qbj33y.
> -EA VALUE--: 0 1 2 3 4 5 6 7 8 9 A B C D E F : (ASCII)
> 00000000 : 62 70 6C 69 73 74 30 30 33 41 B8 D7 E8 A5 0A 7D : bplist003A.....}
> 00000010 : BB 08 00 00 00 00 00 00 01 01 00 00 00 00 00 00 : ................
> 00000020 : 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
> 00000030 : 00 11 : ..
なんでしょうね。なんかコメントを保存してたような気がしますが、忘れました。
とにかく、何を意味しているかを確認する必要はないです。
16進ダンプした値が同じだったら、ちゃんと保存されてます。
------------------------------------------------------------------------
大抵の「本物の拡張属性」は、自動的に付くものであり、ユーザは気にしてない
ので、喪失してもバレません。
ただし、ユーザが意図的に追加した「本物の拡張属性」が喪失すると、バレます。
ファイルを右クリックして「情報を見る」を選択し、「Ohayo」のような馬鹿馬鹿
しいタグを追加してみてください。これは「本物の拡張属性」に保存されます。
また、「コメント」に何か書き込んでみてください、これも「本物の拡張属性」に
保存されます。
これらはユーザが意図的に付けた「本物の拡張属性」なので、喪失すると
バレます。
--
HAT
netatalk-ja メーリングリストの案内