microsoft
%temp%\GovCompDisc_Log_(stamp).log naming conflicts fail concurrent builds
The sbom generator evidently creates a temporary file in a shared location, and assigns a timestamp to the filename. But in concurrent builds, second-resolution isn't enough to guarantee uniqueness, and we see builds frequently fail due to log file access conflicts.
For example, this command failed:
C:\Users\andarno\source\repos\VS-Platform\packages\Microsoft.ManifestTool.CrossPlatform.2.1.31\Content\Microsoft.ManifestTool.dll Generate -b C:\Users\andarno\source\repos\VS-Platform\bin\Shell\Terminal\Setup\x64\Debug\net472\win-x64\ -bc C:\Users\andarno\source\repos\VS-Platform\src\Shell\Terminal\Setup\x64 -pn Terminal.Setup.x64 -pv 1.0.0 -m C:\Users\andarno\source\repos\VS-Platform\bin\Shell\Terminal\Setup\x64\Debug\net472\win-x64_manifest
with this error:
[ERROR] SafelyExecute logged IOException: The process cannot access the file 'C:\Users\andarno\AppData\Local\Temp\GovCompDisc_Log_20220912090327.log' because it is being used by another process.
There were many more project builds that were running similar commands simultaneously. Can the log either be written to a directory we provide at the command line, or can a reliably random suffix be added to the filename to guarantee uniqueness?
Originally reported at https://github.com/microsoft/sbom-tool/issues/134
Looks like we use yyyyMMddHHmmss as the timestamp format:
https://github.com/microsoft/component-detection/blob/dae0b000f4d3d8f8873d13f49fa54c1e69be7ac4/src/Microsoft.ComponentDetection.Common/FileWritingService.cs#L13
Updating this to include milliseconds^1, yyyyMMddHHmmssfff, should be sufficient.
