背景：私のディレクトリにファイルセットがあり、ファイル名順に1つのファイルにマージします。私はそれらt1.txt, t2.txt, t3.txt...を整数の順序でマージすると呼びます。
状態：いくつかの理由で、将来のファイルマージ操作のためのメタデータとしてファイル名を削除したいと思います。
アクション：以下に基づくファイルマージシステムへの移行を検討しています。ファイルが生成された日時（明らかに、後でマージする順序でファイルを作成する必要があります。）
質問：
日付/時刻ソートファイルのマージは安定していますか？隠された問題がありますか？一部のファイルは、10分の1秒以下の間隔で作成されます。これは致命的な欠陥ですか？
ソートされたマージについて考慮する必要がある他のものはありますか？
日付/時間は私にとって簡単に見えます。 OTHは、最初は単純で簡単に見えることが最終的に想像よりも複雑になることがよくあります。だから私は尋ねた。
ベストアンサー1
ほとんどのUnixシステムはファイル作成時間を追跡しません。ファイルが作成されるたびに更新されるファイル変更時間を追跡します。ファイルが生成されたときに順番に書き込まれ（つまり、2番目のファイルが作成される前に最初のファイルが完全に書き込まれ）、その後に変更されていない場合、変更時の順序はファイルが生成された順序と同じです。ただし、更新されると複雑なシナリオでは異なる場合があります。
変更時間（mtime）に加えて、すべてのUnixシステムには、アクセス時間（atime）とinode変更時間（ctime）という2つの異なるファイルタイムスタンプがあります。アクセス時間はファイルを読み取ると更新されますが、パフォーマンス上の理由から、一部のシステム（特にデフォルトではLinux）は常に更新されません。 inode変更時間は、ファイルの一部のメタデータ（名前、権限など）が変更されたときに更新されます。ファイルの書き込み時にも更新されますが、atime が変更されてもファイルを読み取るときは更新されません。 atimeとctimeはどちらも役に立ちません。
多くの歴史的なUnixシステムは、1秒の解像度でファイルタイムスタンプを追跡します。最新のUnixシステムはより良い解像度を持つ傾向がありますが、これには複数のプレイヤーの注意が必要です。
- 使用するカーネルは、より細かい時間分解能をサポートする必要があります。
- ファイルシステムは、これより細かい時間分解能を保存できるはずです。
- チェーン内のすべてのコンポーネント（NFS上のファイル用のNFSサーバーなど）は、これらのより正確な時間検証をサポートする必要があります。
- ファイルをコピーするために使用されるすべてのツール（アーカイバ、ネットワーク同期デバイスなど）は、ほんの数秒よりも細かい時間分解能を維持できるはずです。
- ファイル時間を読み取るアプリケーションは、1秒未満の解像度を考慮する必要があります。既存のUnixプログラミングインタフェースはファイルタイムスタンプの1秒未満の解像度をサポートしていないため、アプリケーションは比較的最新のAPI（POSIX：2008標準化- 採用はそれほど速くないので、まだ比較的新しいものです.)
チェーン内の誰もがナノ秒タイムスタンプをサポートしていても、ファイルが実際に2クロックサイクル以上離れて作成された場合にのみ、ファイルに異なるタイムスタンプがあります。カーネルがナノ秒を記録することを保証しないからです。気づく2つのファイル生成の間に1ナノ秒以上が経過しました。時計を読むには時間がかかりますので、必ずしも完了するわけではありません。ファイルを開いてデータを書き込んで次のファイルに移動する前にファイルを閉じるスレッドがある場合、1秒未満の解像度を記録するほとんどすべての既存のシステムは異なるタイムスタンプを記録すると考えますが、リスクは最小限に抑えられます。 。 （他のスレッドがファイルに書き込むと、マイクロ秒の解像度でもタイムスタンプの競合が発生する可能性がありますが、通常この場合、順序に依存することはできません。）
したがって、コンピュータが今よりもはるかに高速でない限り、使用しているすべてのツールが1秒未満の解像度をサポートしている場合は、可能で安定していました。ただし、クロック障害が発生した場合、または1秒未満のタイムスタンプをサポートするためのツールを確認しないと脆弱です。エラーが発生する可能性が低いようにファイル名を使用することをお勧めします。