多くの一般的なファイルシステムではアトミック操作は提供されていませんが、アトミックにファイルを書き込むことは特定のシナリオでは非常に重要です。私はこの問題の解決策を思いつきました。非トランザクションファイルシステムでのアトミックファイル書き込みの実装
Iは、以下の仮定を行った：
- 使用中のファイルシステムは、（例えば、NTFS）iノード・レベルでアトミック操作をサポートします。これは、がとの削除がアトミックであることを意味します。
- プログラム自体がファイルにアクセスします。
- プログラムのインスタンスは一度に1つしかなく、シングルスレッドで動作します。
- 簡単にするために、ファイル内容全体が毎回書き込まれます（つまり、切り捨て - 書き込み）。
これは、次のような問題があります。ファイルを書き込んでいるうちに、プログラムが中断され、書き込むコンテンツの一部だけが残ってしまう可能性があります。
は、私は次のプロセスを提案：
- は一時ファイルに新しいコンテンツを書く新
- 移動元のファイルを一時的な場所へオリジナルバックアップ
- 移動新 〜オリジナル
- バックアップ
新とバックアップを削除ファイルは、（例えば、彼らは異なっ前置することができ、または同じボリューム上の別のディレクトリにすることができる）オリジナルファイルと区別されています。同時に、その名前は対応するオリジナルに直接マッピングする必要があります（たとえば、同じファイル名を使用するなど）。
しかし、この操作はまだアトミックではありません。プロセスは、ステップ1、2、3または4中断することができる：
- 潜在的に不完全新規を残します。
- 移動はアトミックですが、ターゲットファイルが失われています。 新しいとバックアップが存在し、完了です。
- 移動はアトミックですが、使用されていませんバックアップです。 オリジナルは、に置き換えられました。新しい内容
- 削除はアトミックです。
前提条件2と3を前提として、クラッシュ後にプログラムを再起動する必要があります。起動プロセスの間に、それはこれらの回復のチェックを実行する必要があります。
- 新が存在するが、バックアップが、我々はそれが不完全になる可能性があるので新しいを削除する手順1で以降に墜落していない場合。
- 新が存在し、バックアップは、あまりにも、私たちはバックアップが存在しますが、手順3で続行した後新は、あまりにも、私たちがクラッシュしていない場合は、ステップ2は、ステップ3
- を続行した後、墜落しない場合
リカバリプロセス自体は、アトミック操作のみを使用しているため、中断後に中断したところでそのまま続行されます。
私は、このアイデアが1つのプログラムのアトミック書き込みを保証すると考えています。
- 同じプログラムの複数のインスタンスを使用する場合、現在進行中のファイル書き込みで他のプログラムに干渉することがあります。
- 通常は書き込むだけの書き込みをしない外部プログラムは通常正しい結果を得ますが、同時に要求されたエントリに書き込み操作があると、間違ってエントリが見つからないことがあります。
これらの問題（前の前提条件で除外されています）は、使用ポリシー（たとえば、他のインスタンスを確認し、他のユーザーへのディレクトリアクセスを拒否する）によって解決できます。
最後に、私の質問：それは意味があるのでしょうか、それともプロセスに欠陥がありますか？このアプローチが実際に使用されないようにする問題はありますか？
私はこれにいくつかのC＃コードを書いていますが、私は要求に応じて追加することができましたが、質問はすでに1マイルほどです。 – mafu