FileStream locks files with shared lock on Unix

On Unix, if you open a file using FileStream with FileAccess.Read permissions only, and then call FileStream.Lock(Int64, Int64) to lock a region of the file, the operation will now succeed. It succeeds because the runtime locks the file with a shared or read lock instead of a write lock.

using (FileStream fs = File.OpenRead("testfile")) // Opening with FileAccess.Read only
{
    fs.Lock((long) 3, (long) 1); // Attempting to lock a region of the read-only file
}

There's no change to the behavior on Windows, where the operation always succeeded.

Previous behavior

On Unix, if you opened a file using a FileStream with read permissions only, and then called FileStream.Lock(Int64, Int64) to lock a region of the file, the runtime attempted to lock the file with a write lock. That resulted in an UnauthorizedAccessException and the message "Access to the path is denied".

New behavior

Starting in .NET 6, if you open a file using a FileStream with read permissions only on Unix, and then call FileStream.Lock(Int64, Int64) to lock a region of the file, the runtime locks the file with a read lock (also known as a shared lock).

Version introduced

.NET 6 RC 1

Type of breaking change

This change can affect binary compatibility.

Reason for change

FileStream.Lock(Int64, Int64) is the API that lets users lock a specific region of a file. There's no API that lets you choose the underlying locking method, so FileStream.Lock(Int64, Int64) should correctly determine the appropriate locking method for the file permissions.

Prior to .NET 6, to be able to lock the file, you had to do one of the following:

If you used one of these workarounds, you can now remove them.

Affected APIs