NuGetScratch lock files are not cleaned up

[tmds]

NuGetScratch lock files are not removed when the dotnet command that created them exited.

For example:

$ dotnet --version
5.0.102
$ tree NuGetScratch
NuGetScratch [error opening dir]

0 directories, 0 files
$ dotnet new console -o console
The template "Console Application" was created successfully.

Processing post-creation actions...
Running 'dotnet restore' on console/console.csproj...
  Determining projects to restore...
  Restored /tmp/console/console.csproj (in 126 ms).
Restore succeeded.

$ tree NuGetScratch
NuGetScratch
└── lock
    ├── 60b0ce340dbeb990efe4eb3dc37072e604096ae1
    ├── 7d89499164269649a3ec6f9c8b4f921bf93d8c0a
    └── 9bcf2ad385812bad4415e1035a0688c2be3aa708

1 directory, 3 files

[heng-liu]

Hi, thanks for reporting this issue!
Sorry, looks like we dispose lock file in temp folder on Windows, but not Linux/Mac, due to some concurrency issues.
So you have to clean it up by running dotnet nuget locals temp --clear command. (https://docs.microsoft.com/en-us/nuget/consume-packages/managing-the-global-packages-and-cache-folders#clearing-local-folders)

[tmds]

due to some concurrency issues.

Can you give more info about these concurrency issues? Or point me to the code?

[heng-liu]

Hi @tmds , I haven't looked into what are the exact issues, but people encountered the issues before so we use different FileOptions for Windows and other platforms at
https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.Common/ConcurrencyUtilities.cs#L200-L212

[tmds]

Looks like this was introduced in NuGet/NuGet.Client#431.

Let's see what happens if we use DeleteOnClose on Linux. Maybe .NET is handling this better than 5 years ago.

[zivkan]

I don't know the underlying cause of the concurrency issue, but our tests in NuGet.Common.Tests will check it, if you comment out all usage of PerFileLock. For slightly more details, see NuGet/NuGet.Client#4123 (review)