ファイルロック
flockにもfcntlにも、他のオペレーティングシステムに慣れたプログラマから見ると奇異な点がある。
flockは NFS などのネットワークファイルシステムでは実装により機能しない場合がある。BSDでは何も起きないし、Linuxではエラーとなる。同じファイルへの(ひとつのプロセスからの)flock呼び出しは、ロックの状態を変更する(共有から排他へ、あるいは排他から共有へ)。しかし、このとき一時的に古いロックを外してから新しいロックをかける。例えば、排他ロックから共有ロックにかけ変えようとしたとき、一瞬の隙をついて別のプロセスが排他ロックをかけたら、元々ロックをかけていたプロセスが締め出されてしまう。
プロセスはひとつのファイルに対応するファイル記述子を複数個持つことができる。このうちのいずれかを使ってfcntlでロックをかけていたとする。このとき、同じファイルに対応する別のファイル記述子をクローズすると、そのファイル上にそのプロセスが設定した全ロックが解除されてしまう。また、fcntlのロックは子プロセスに受け継がれない。このfcntlのクローズに関連した動作は、ライブラリのサブルーチン内でファイルにアクセスすることが多いアプリケーションなどで問題を発生することが多い。
Windowsでの共用ファイルアクセスは以下の3つの機構で管理される。
共用アクセス制御を使用して、アプリケーションにファイル全体へのリード/ライト/削除を許可する。
バイト単位のロックを使用して、ファイル内の一部分へのリード/ライトを裁定する。
Windowsのファイルシステムは、実行中ファイルについて、ライトまたは削除のためにオープンすることを拒否する。
Windowsでの共用アクセス制御はMS-DOS 3.3で導入されたものを受け継いでいる。アプリケーションは明示的に共有を許すか、排他的なリード/ライト/削除をファイルに対して行う。その他のアクセス種別として、ファイル属性へのアクセスを許すなどがある。
共用アクセスのあるファイルについて、アプリケーションがバイト単位のロックを使ってファイルの特定の領域へのアクセスを制御する場合もある。バイト単位のロックはファイルの一部(オフセットと長さ)とロック種別(共有か排他か)を指定する。ロックされる領域が実際のファイルの大きさに収まっている必要はなく、中にはこの機能を利用したアプリケーションもあることに注意が必要である。
Windows上でファイルのリード/ライトAPIを使うアプリケーションについては、Windows内のファイルシステムが強制的にバイト単位ロックを設定する。Windows上でファイルマッピングAPIを使用するアプリケーションの場合、バイト単位ロックは強制されない。バイト単位ロックには他の副作用もある。例えば、Windowsのファイル共有機構では、クライアントがファイルアクセス時にバイト単位ロックをかけると、自動的に全クライアントのファイルキャッシュを無効化する。