The process cannot access the file because it is being used by another process – TortoiseGit status cache under concurrent requests

Short answer

There is no exact concurrency threshold and no documented maximum number of simultaneous TortoiseGit UI operations. Windows error 32 is a sharing violation: another process holds a file—most often .git/index—in a way that conflicts with the requested access. On a working copy larger than 10,000 files with real-time antivirus scanning .git, contention may appear with only a handful of simultaneous context menus, commit dialogs, or log views, but that is an environment-specific symptom pattern, not a fixed limit.

Reducing the status cache refresh interval—making scans more frequent—generally does not lower the probability of error 32. Increasing the interval can lower it by reducing background scan frequency, at the cost of stale overlays. Excluding the exact .git/index path from real-time antivirus scanning can remove the dominant lock source and preserve icon overlays, provided antivirus is the lock holder.

Likely explanation vs confirmed facts

Confirmed: error 32 means a conflicting open handle exists. TortoiseGit's shell status cache and icon overlays read working-copy metadata, including .git/index, to compute status. Concurrent UI operations can trigger multiple cache or status reads. A repository with more than 10,000 files makes each status pass longer, widening the collision window.

Likely, but not confirmed for your machine: real-time antivirus scanning .git/index is the external lock that extends the critical section. TortoiseGit's cache may serialize its own requests, but it cannot control antivirus, Windows Search, backup agents, or other Git processes. The exact number of simultaneous UI operations at which error 32 appears is therefore not portable.

Diagnose the lock holder first

Ask one missing diagnostic detail: when error 32 occurs, which process holds .git/index? That changes the recommendation.

1. Run Process Monitor as administrator. Add filters: Path ends with \.git\index; Operation is CreateFile; Result is SHARING VIOLATION. Reproduce with three to five simultaneous TortoiseGit UI operations.
2. Note the Process Name and stack. If it is your antivirus, exclusion is the highest-yield step. If it is TortoiseGitCache.exe or git.exe, tune cache concurrency or refresh instead.
3. Optionally check open handles: handle.exe -a "C:\path\to\repo\.git\index" (Sysinternals, elevated). This shows current holders, not the full sharing-violation history.

Scoped fixes

If antivirus is the holder

Exclude the exact repository's .git\index from real-time scanning. If that works, consider also excluding .git\objects and .git\HEAD for that repository, but keep the exclusion narrow. This preserves icon overlays and the status cache. Security tradeoff: excluded paths are not scanned in real time; scope the exclusion to a trusted working copy, not all of C:\.

If TortoiseGit cache contention remains

Increase the status-cache refresh interval rather than shortening it. A longer interval means fewer background scans and shorter aggregate lock windows, but overlays may not reflect external changes until the next scan. In TortoiseGit settings, look under Icon Overlays or Status Cache for the refresh interval; the exact label varies by version. Test 30 seconds or more.

Some TortoiseGit builds reportedly support an undocumented per-user CacheMaxParallel DWORD under HKCU\Software\TortoiseGit. Treat this as version-dependent and verify before relying on it. To inspect:

reg query "HKCU\Software\TortoiseGit" /v CacheMaxParallel

If present, setting it to 2 and restarting explorer.exe can throttle parallel overlay requests. Do not assume it exists in your version.

What not to do first

Do not disable icon overlays as the first move. Excluding the index file and lengthening the refresh interval usually preserve overlays. If error 32 persists after antivirus exclusion, check Windows Search indexing, backup tools, and any Git GUI or IDE that scans the same working copy.

Verification

Repeat the same concurrent UI scenario after each change. Compare Process Monitor sharing-violation counts for .git\index. A drop in violations with acceptable overlay freshness is success. If the lock holder changes, revisit the fix. Assumption: TortoiseGit 2.x on Windows with the shell status cache; exact settings labels and undocumented registry values require verification for your build.