Linux : After using SQlite Connection to connect to the database, then using File.Open should report “ it is being used by another process” exception

[jinzhao1127]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

On Linux OS, after using SQlite Connection to connect to the database, then using File.Open, it does not report any error.

Expected Behavior

It should throw the error: The process cannot access the file '...Temp\tmp4ur3by.tmp' because it is being used by another process.

Steps To Reproduce

1. Install the latest .NET 8.0.412 SDK on Linux Ubuntu Server 24.04 LTS machine
2. Execute the code below:
   File.Open(fileName, FileMode.Open, FileAccess.Read, FileShare.None)
3. Execute the project
   It does not report any error

The repro project project get from: https://github.com/jinzhao1127/UsageDatabase_CloseOpen.git
For windows side, it will throw eception:

Exceptions (if any)

No response

.NET Version

aapt@UBMark18001:~$ dotnet --info
.NET SDK:
 Version:           8.0.412
 Commit:            819e1a9566
 Workload version:  8.0.400-manifests.9cf71931
 MSBuild version:   17.11.31+933b72e36

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  24.04
 OS Platform: Linux
 RID:         linux-x64
 Base Path:   /home/aapt/dotnet/sdk/8.0.412/

.NET workloads installed:
Configured to use loose manifests when installing new manifests.
There are no installed workloads to display.

Host:
  Version:      8.0.18
  Architecture: x64
  Commit:       ef853a7105

.NET SDKs installed:
  8.0.412 [/home/aapt/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 8.0.18 [/home/aapt/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 8.0.18 [/home/aapt/dotnet/shared/Microsoft.NETCore.App]

Anything else?

No response

[martincostello]

Looks like this issue should be transferred to dotnet/runtime, unless it's a SQLite issue, as it doesn't appear to be specific to ASP.NET Core.

[h5aaimtron]

@jinzhao1127 @martincostello
Windows enforces an exclusive lock with FileShare.None where-as Linux supports advisory locks. Unfortunately, advisory locks require the other process trying to access the same file to adhere to the lock, and they may not. I don't believe this is 100% possible on Linux due to these opposite approaches at the OS level.