コピーが正しいことを確認するために、macOSを使用していくつかのファイルをHFS +にコピーしました。 macOSによると、コピーされたファイルの所有者は501ですls -han。
その後、HFS + USBスティックをUbuntuに接続しましたが、それによると、ファイル所有者は1000人ですls -han。なぜ？
その後、Ubuntuが所有する501ファイルの1つを同じHFS +ボリュームにコピーしてみましたcp -a。
macOSはls新しいファイルをユーザー1000が所有しているものとして扱います。
本当に？わかりません。所有者のユーザーIDも保存しない場合は、そのオプションを使用するのcpはなぜですか？-a私が逃したものは何ですか？
修正する:明確にすると、私の考えでは、HFSが基本的にUnixファイル権限をサポートし、「ただ動作する」必要があるという事実で混乱が起こると思います。
私は最近、cpsがpreserve=timestamps実際にタイムスタンプを保存していないことを知りました（作成日がリセットされました）。今、所有権が維持されないと信じていますかpreserve=ownership？
答え1
~からhfsplusこのモジュールのLinuxカーネルドキュメント:
インストールオプション
uid=n、gid=n
初期化されていない権限構造を持つファイルシステム内のすべてのファイルを所有するユーザー/グループを指定します。デフォルト：インストールプロセスのユーザー/グループID。
501は、最新のmacOSの一般ユーザー向けの最初のデフォルトのUIDです。
したがって、macOSは一部のファイルの「権限構造」を初期化しないようです。返品、Apple 技術ノート #1150所有者IDの保存に追加の問題があります。
所有者ID
ファイルまたはフォルダーの所有者の Mac OS X ユーザー ID。 10.3より前のバージョンのMac OS Xでは、ユーザーID 99を現在コンソールにログインしているユーザーのユーザーIDとして扱いました。コンソールにログインしているユーザーがいない場合、ユーザーID 99はユーザーID 0（root）として扱われます。 Mac OS X バージョン 10.3 は、ユーザー ID 99 を呼び出しプロセスのユーザー ID として扱います (実際、すべての人が同時に所有するようになります)。これらの置換は実行時に発生します。ディスクの実際のユーザーIDは変更されません。
それから：
メモ:
fileModeフィールドのS_IFMTフィールド（上位4ビット）が0の場合、Mac OS Xは権限構造が初期化されていないと仮定し、内部ですべてのフィールドにデフォルト値を使用します。デフォルトのユーザーとグループIDは99ですが、ボリュームのマウント時に変更できます。このデフォルトの所有者IDは上記のように置き換えられます。
これは、Mac OS 8および9で生成されたファイルまたは権限フィールドをゼロに設定する他の実装では、そのファイルの所有権を無視するオプションが無効になっていても、そのファイルに対して所有権を無視するオプションが有効になっているかのように動作します。フルボリューム。
ここで言及されているS_IFMTは16ビット値の上位4ビットであり、Unixスタイルの許可ビット（3x読み取り/書き込み/実行およびsetuid/setgid/stickyビット）を格納するために使用されます。一般ファイルでは、上位4ビットをゼロ以外の特定の値（）に設定する必要がありますS_IFREG。それ以外の場合、上記の以前のバージョンとの互換性メカニズムが開始されます。
HFS +ファイルシステムの構造は、時々ファイルの所有権を「迅速かつ緩やかに」処理する可能性を開きます。
リムーバブルメディアの場合、メディアにファイルを書き込むシステムがファイルを読み取るシステムと異なる場合があり、両方のシステムのUIDマッピングが完全に異なり、不便になる可能性があるため、macOSで「所有権を無視する」オプションを自動的に有効にすることが合理的です。ユーザーに。
したがって、これは、macOSがリムーバブルメディアでユーザーフレンドリーになるように努力し、リムーバブルメディアに対するユーザーの物理的所有権がその中のデータの所有権証明と同じであると仮定することです。
Ubuntuの最初の一般ユーザーアカウントはUID 1000で作成され、これは明らかにHFS +ボリュームをUbuntuにマウントするアカウントです。
Linuxで生成されたファイルはmacOSでUID 1000を保持するため、Linuxは〜するHFS+「権限構造」をファイル所有者のUIDで埋め、macOSがそれを読むと、期待どおりに機能します。
クラシックPOSIXタイムスタンプは次のとおりです。
ctime=最後のステータス/メタデータ変更時間mtime=コンテンツが最後に変更された時間atime=最後のアクセス時間。
作成時間（crtimeまたは出生時間）はそのうちの1つではありません。ファイルシステムは作成時間をサポートすることも、サポートしない場合もあります。正確な意味は、ファイルシステムの種類とUnixスタイルのオペレーティングシステムによって異なります。
crtime一部のファイルシステムドライバは内部で作成時間の割り当てを処理し、後でファイル時間を変更することはまったく不可能です。これらのファイルシステムでは、誤ってバックアップから削除して復元したファイルのクラシック時間ctimeとmtime復元時間がある可能性がありますが、作成時間はファイルが存在しなくなったため、バックアップから復元までの時間を反映しています。オリジナル、それでもその正確なコピー。
ファイルをコピーするときは明らかに新しいファイルの作成：コピージョブで「生成時間を保存する」という考えは矛盾です。
ファイルシステム自体は、ファイルの作成時期を追跡できます。文書しかし、これは作成時間と必ずしも同じではありません。ファイルのデータ。後者を追跡するには、通常、データが生成された時間のメタデータフィールドを含むことができるバージョン管理システムまたはファイル形式が必要であり、そのデータ型を使用するすべてのアプリケーションは「コンテンツ」の意味に同意する必要があります。 「. データ生成時間」を入力しないと意味がありません。