aa901c4111
Windows exposes mapped drives twice and the two views disagree. Captured on one box at one moment, same two mappings: Get-SmbMapping reported OK for both while net use reported Disconnected and Reconnecting. Collecting only Get-SmbMapping - the nicer, more structured one - would have reported a healthy Q: on a machine whose Q: was down, which is the exact failure this telemetry exists to catch. So collect both and keep them apart. The probe emits netuse and smbmapping as separate keys and does not reconcile them; the disagreement is the signal and normalising it in the agent would discard it before anyone could see it. The server merges by drive letter and shows the WORSE of the two. A drive that either source calls broken is broken for the operator, and a drive neither source gave a status for renders as Unknown rather than blank - an unannotated row reads as healthy, so a failed check would present as a working drive. Drives seen by only one source are kept, not dropped: Get-SmbMapping is absent on some builds and session types, and requiring agreement would silently hide every mapped drive on those machines. No active reachability testing. Windows already knows the status, so touching each share would be wasted work and would reintroduce the hang risk the bounded probe exists to avoid. The probe stays unelevated in the operator's session. UAC token separation gives an elevated context a different mapped-drive table, often empty, so elevating this later would quietly empty the card. Adds a commented-out remap_drive seam in the command catalog. Not implemented, but placed so the next person finds the user-session and elevation constraints before writing it rather than after. The merge logic has no test coverage yet; the docstring names the three behaviours that must not be broken.
13 KiB
13 KiB