Windowsのデフォルトは、自動で必須のファイルロックです。UNIXはデフォルトで手動の協調ファイルロックを行います。どちらの場合もデフォルトは上書きできますが、どちらの場合も通常は上書きされません。
古いWindowsコードの多くはfopen
、ネイティブAPI(などの関数)ではなく、C / C ++ API(などの関数)を使用していますCreateFile
。C / C ++ APIでは、強制ロックがどのように機能するかを指定する方法は提供されていないため、デフォルトを取得します。デフォルトの「共有モード」は、「競合する」操作を禁止する傾向があります。書き込み用にファイルを開くと、実際にファイルに書き込みを行わない場合でも、書き込みは競合すると見なされます。名前の変更についても同じです。
そして、ここから悪化します。C / C ++ APIには、読み取りまたは書き込み用に開くこと以外に、ファイルをどうするかを指定する方法がありません。したがって、APIは、ユーザーが合法的な操作を実行することを前提としています。ロックは必須であるため、コードが競合する操作を実行するつもりはなく、別の目的でファイルを開いているだけであっても、競合する操作open
を許可するが拒否されます。
したがって、コードがC / C ++ APIを使用する場合、またはこれらの問題を特に考慮せずにネイティブAPIを使用する場合、開いているすべてのファイルで可能な操作の最大セットを防止し、可能な操作がない限りファイルを開くことができなくなります開かれた後、それで実行することができます競合していません。
私の意見では、すべてのプログラムが共有モードとオープンモードを賢明に選択し、障害のケースを正常に処理した場合、Windowsの方法はUNIXの方法よりもはるかにうまく機能します。ただし、コードがこれらの問題を気にしない場合は、UNIXメソッドの方がうまく機能します。残念ながら、基本的なC / C ++ APIは、共有モードと競合するオープンを適切に処理する方法でWindowsファイルAPIにうまくマッピングされません。そのため、最終的な結果は少し乱雑です。