Trim UnixFileSystemTypes to the values .NET runtime cares about.

[tmds]

@am11 @stephentoub @jkotas @adamsitnik ptal.

[tmds]

The behavior here is changing. Previously, if we didn't recognize the type as one of the values in UnixFileSystemTypes then no locking was performed. Now, we'll do locking unless the type is nfs/smb/cifs.

I assume we're ok to do this as return true also happens in earlier checks.

This does mean that we rely on the string names in PAL to be correct for identifying nfs/smb/cifs.

[am11]

This does mean that we rely on the string names in PAL to be correct for identifying nfs/smb/cifs.

Isn't it the same as main branch? f_type on linux (comparison with magic integers) and f_fstypename / f_basetype on other Unix (string comparison with strcmp)

[tmds]

Suppose we have the names wrong.

On the main branch, MapFileSystemNameToEnum returns zero, then TryGetFileSystemType return false and then CanLockTheFile will return false.

With the new implementation, FileSystemNameSupportsLocking returns 1 and then FileSystemSupportsLocking will return true.

[jkotas]

The comment above says "// LOCK_SH is not OK when writing to NFS, CIFS or SMB". Why is it not OK? What's the failure more?

I am trying to better understand the downside of enabling locking by default for all file systems except the few we explicitly check for.

[tmds]

Locking is enabled by default to match Windows behavior.
(For example: you get an exception when the SDK tries to write the same file simultaneously.)

The code is filtering for a combination that doesn't work well.
The combination seems to be: LOCK_SH + FileAccess.Write + nfs/smb/cifs.
And the referenced issues mention silently discarded writes and throwing on dispose (#44546, #53182).

[am11]

Looks great. Thanks! :)

[tmds]

Thanks for the suggestions/review, @am11!