System.IO.FileStream FileAccessとFileShare
あちこち検索しましたが、この質問に対する答えが見つかりません。 FileAccess がマシン上のファイルアクセスを扱い、 FileShare が共有を扱うことを理解していますが、それがどのように組み合わされ、それらがどのように影響するかについての説明は見つかりませんお互い。
たとえば、
using ( FileStream fs = new FileStream( pathName, FileMode.Open, FileAccess.Read, FileShare.ReadWrite) )
これは、マシンのユーザーがファイルを読み取ることができるのは、リモートでフォルダーにアクセスしているユーザーがファイルを読み書きできることを意味しますか？さらに、使用に影響はありますか
using ( FileStream fs = new FileStream( pathName, FileMode.Open, FileAccess.Read ) )
FileShareを指定していない場合
FileAccessは、ファイルをどう処理するかを示します。理解しやすいので、読み書きすることがわかります。
FileShareは、別のプログラマーの立場に踏み込む必要があるため、はるかに扱いにくいものです。ファイルが開かれている場合に別のプロセスが実行できることを決定します。ファイルにアクセスする2つのプロセスは非常に面倒な場合があります。考えられる障害モードを推論する必要があります。選択する値は、ファイルのタイプおよび必要なアクセスと強く相関しています。あなたがやろうとしていることによってそれを分解する：
FileAccess.Read
別のプロセスもファイルから読み取る場合、問題はありません。したがって、FileShare.Readがデフォルトの選択です。
別のプロセスが書き込み用にファイルを既に開いている場合は、FileShare.ReadWriteが必要になることがあります。すでに書き込みアクセス権を取得しているため、FileShare.Readだけでは自分でファイルを開くことはできません。他のプロセスが最初だったため、書き込みを拒否することはできません。代わりにアクセスが拒否されます。これは通常、他のプロセスがテキストをファイルの最後に追加するだけであることが確実であるようなテキストファイルでのみ有効になります。ログファイルは非常に一般的なシナリオです。まだトリッキーかもしれませんが、そのプロセスが変更をファイルにフラッシュするタイミングが問題になります。あなたは部分的に書かれたテキストの行を観察するかもしれません、これに注意してください。
FileAccess.Write
FileShare.WriteまたはFileShare.ReadWriteは使用できません。これにより、2つのプロセスが同時にファイルに書き込むことができるため、ファイルの内容は両方のプログラムからの乱雑な出力になります。可能な回避策は、ファイルへのアクセスを調停するこれらのプロセスであり、プロセスの1つだけが同時にファイルにアクセスできることを保証します。通常、名前付きミューテックスによって実装されます。
FileShare.Readがテキストファイルの場合は、上記でログファイルを使用して説明したのと同じシナリオを使用できます。それ以外の場合、デフォルトの選択肢はFileShare.Noneです。
FileAcces.ReadWrite
それほど一般的ではありません。バイナリデータを書き込んでSeek（）を使用する場合にのみ使用されます。これを行っている間、他のプロセスがファイルを正しく読み取ることができるとは考えていません。アクセスを自分で調停しないと仮定すると、FileShare.Noneを使用する必要があります。
FileShareは、ネットワーク上で共有されるドライブとは何の関係もありません。これは、他のプロセスがファイルにアクセスする方法を示します。
最初のプロセスがFileShare.Readでファイルを開く場合、他のプロセスはFileAccess.Readでファイルを開くことができますが、その場合、別のプロセスはFileAccess.Writeでファイルを開くことができません。
FileShareは、Windowsファイル共有とは関係ありません。同じマシンでのみファイルを共有することについて話します。それはあなたが最大限に実行できるようになった後に来る他のファイルハンドルを指定します。また、既存のハンドルがそれと比較され、ファイルを開くことができるかどうかが決定されます。
FileAccessはyourアクセス権を指定します。