Fix PID-recycling race in orphan-lock detection

[tyrielv]

Summary

Fix a PID-recycling race in GVFSLock's orphan-lock detection. When the lock holder exits and Windows quickly recycles its PID to an unrelated process, IsProcessActive(pid) returns true and GVFS concludes the lock is still held — the next git command then either waits the full 300 s timeout or prints a spurious "Waiting for '' to release the lock" message and an empty stderr assertion fails.

This surfaced as flake in the OrphanedGVFSLockIsCleanedUp functional test on busy CI agents (two failure modes: 300 s timeout, and the "Waiting for…" assertion). The same race can affect users when the OS quickly reuses a freed PID.

The fix

Process-identity tracking via creation time:

• When the lock is granted to an external requestor, capture the process's creation timestamp (GetProcessTimes, an opaque 100-ns FILETIME) alongside its PID.
• On every orphan check, look up the current creation timestamp at that PID and compare. The process is gone → orphan. A different process at the same PID → start-time mismatch → orphan.

Design notes

• No protocol change. Capture happens server-side in Mount when the lock request arrives. The hook's git.exe parent is blocked on the synchronous pipe send/receive, so it's guaranteed alive when Mount captures.
• GetProcessTimes alone is not enough — it still returns a creation time for terminated processes whose kernel object lingers due to an outstanding handle elsewhere. The Windows implementation combines GetExitCodeProcess (STILL_ACTIVE check) with GetProcessTimes.
• Acquisition does not fail if start-time capture fails. The existing IsProcessActiveImplementation has a Process.GetProcessById fallback for cross-integrity callers that OpenProcess(QueryLimitedInformation) cannot open; we preserve that compatibility surface. A HasStartTime flag is stored alongside the PID; when false, the orphan check falls back to the legacy IsProcessActive call (the pre-fix behavior). The fallback is recorded in telemetry (StartTimeUnavailable=true on TryAcquireLockExternal).
• Improved telemetry. ExternalLockHolderExited now carries an ExternalHolderTerminationReason field (ProcessNotActive | PidRecycled | Unknown) for easy post-mortems.

Files changed (7, +231/-10)

File	Purpose
GVFS.Common/NativeMethods.Shared.cs	Add GetProcessTimes P/Invoke
GVFS.Common/GVFSPlatform.cs	New abstract TryGetActiveProcessStartTime
GVFS.Platform.Windows/WindowsPlatform.Shared.cs	TryGetActiveProcessStartTimeImplementation (combined active-check + start-time)
GVFS.Platform.Windows/WindowsPlatform.cs	Override
GVFS.Common/GVFSLock.cs	Capture start time at acquisition, identity-check on orphan detection, plumb termination reason to telemetry
GVFS.UnitTests/Mock/Common/MockPlatform.cs	Mock + ProcessStartTimes dictionary for tests
GVFS.UnitTests/Common/GVFSLockTests.cs	2 new tests: WhenHolderPidRecycled (orphan detected via start-time mismatch), WhenHolderStartTimeMatches (live holder correctly seen as active)

What is intentionally NOT changed

• No change to the named-pipe protocol (LockData wire format is unchanged — full backward compat with older clients/servers).
• No change to GVFS.FunctionalTests.LockHolder.
• No change to the OrphanedGVFSLockIsCleanedUp functional test. The test was correctly exposing the product bug; with the product fix, it passes naturally without any test-side workaround.
• No change to GVFS.Hooks startup PID check (Program.cs:251). That's a one-shot check on the hook's git.exe parent at startup, not a polling loop, so no PID-reuse race.

Validation

• dotnet build GVFS.UnitTests — clean.
• Full scripts\Build.bat Debug — clean.
• GVFS.UnitTests.exe — 815/815 pass, including the two new tests for the identity-check path and all existing tests (which now exercise the start-time-unavailable fallback path).
• Local functional run not informative for this flake (CI-specific).

[dscho]

LGTM!