データベースを構成している物理ファイル全体についてシリアライズ(逐次化)を施す。これで他のプロセスがファイルにアクセスするのを防ぐことができるし、関連するレコード群をロックするよりも事実上効率的かもしれない(多数のレコードロックをかけたり外したりするオーバヘッドを考慮した場合)。実装.Windows.共用アクセスのあるファイルについて、アプリケーションがバイト単位のロックを使ってファイルの特定の領域へのアクセスを制御する場合もある。バイト単位のロックはファイルの一部(オフセットと長さ)とロック種別(共有か排他か)を指定する。ロックされる領域が実際のファイルの大きさに収まっている必要はなく、中にはこの機能を利用したアプリケーションもあることに注意が必要である。Windows上でファイルのリード/ライトAPIを使うアプリケーションについては、Windows内のファイルシステムが強制的にバイト単位ロックを設定する。Windows上でファイルマッピングAPIを使用するアプリケーションの場合、バイト単位ロックは強制されない。バイト単位ロックには他の副作用もある。例えば、Windowsのファイル共有機構では、クライアントがファイルアクセス時にバイト単位ロックをかけると、自動的に全クライアントのファイルキャッシュを無効化する。このため、リード/ライト要求が全てファイルサーバ上の実際のファイルに対して行われるので、ファイルアクセスが遅くなったように感じられるのである。アプリケーションのエラー処理にバグがあるとファイルがロックされて(共有アクセスでもバイト単位ロックでも)、他のアプリケーションからアクセスできなくなる。このとき、不正動作しているプログラムを手動で終了させることでファイルアクセスが可能になるだろう。これは一般に「タスクマネージャ」を使って行う。UNIX.問題点.Linux.TRON.Java.ロックファイル.