Maintenance task tempcleanup deletes every dbatools* item in the temp folder, including ones still in use #10759

What happens

The maintenance task tempcleanup (private/maintenance/tempcleanup.ps1) runs once, one minute after the module is imported:

Get-ChildItem -Path $Env:TEMP -Filter dbatools* | Remove-Item -ErrorAction Ignore -Recurse

It deletes everything in the temp folder whose name starts with dbatools (on Windows regardless of case), with no check of age or ownership. That includes items that are still in use:

• by a command of the same session that happens to run about a minute after the import;
• by any other PowerShell process of the same user, because every import in any process starts its own one-minute timer.

Found while working on #10735

The first version of the per-call request folder in New-DbaComputerCertificate was named dbatools-<fqdn>-<guid>. On PowerShell 7 lab runs the folder disappeared while certreq -new was writing into it: certreq reported "Request Created", then 0x80070003 ERROR_PATH_NOT_FOUND for the CSR, and the pending request stayed behind in LocalMachine\REQUEST. Only one test context failed, whichever ran about a minute after the import. On Windows PowerShell 5.1 the timing was different and everything passed. The test's own dbatoolsci_csr_* folder in the temp folder was hit the same way next. #10735 now uses names that do not start with dbatools.

Other items exposed today

• Install-DbaParquet: extracts into Join-Path ([IO.Path]::GetTempPath()) "dbatools-parquet-<guid>" (line 465). An install that is running when the task fires loses its working folder.
• Invoke-DbaXEReplay: writes its replay script to $temp\dbatools-replay-<timestamp>.sql in begin and feeds it to sqlcmd later.
• The default export path: Path.DbatoolsExport is $docs\DbatoolsExport, and settings/paths.ps1 falls back to the temp folder when the account has no Documents folder (service accounts, some containers). The default export folder is then $temp\DbatoolsExport, and the task deletes the user's exports one minute after every import.
• Tests: any test that puts dbatoolsci_* items directly into the temp folder is exposed to the same one-minute window.

Suggestion

Keep the task, but let it delete only what is clearly stale, for example items whose LastWriteTime is older than a day. That keeps the purpose (tidying up after crashed runs) and removes the race with running work, in this process and in others. Alternatively, dbatools could write its temporary items into one subfolder it owns, and let the task clean only that folder's old content. In both cases the DbatoolsExport fallback should not land directly in the temp folder.

This text was created by Claude and reviewed by Andreas Jordan.