Identify places where file handles are closed and very soon reopened again

[adamsitnik]

As #63912 has shown, there are places in BCL where files are being closed and very soon reopened (it's typically not obvious).

using (FileStream fs = new FileStream(destinationFileName, fMode, FileAccess.Write, FileShare.None, bufferSize: 0x1000, useAsync: false))
{
    using (Stream es = source.Open())
        es.CopyTo(fs);
} // the file is closed

File.SetLastWriteTime(destinationFileName, source.LastWriteTime.DateTime); // it's reopened

It causes two kinds of problems:

• AV and other software can open the file in the meantime, lock the access and hence make the re-opening code fail (ERROR_SHARING_VIOLATION on Windows)
• the perf is not ideal, as opening the files is expensive (especially on Unix where we perform more than 1 sys-call to open a file).

One of the potential solutions would be to use APIs that are accepting SafeFileHandle like #20234

[ghost]

Tagging subscribers to this area: @dotnet/area-system-io
See info in area-owners.md if you want to be subscribed.

Issue Details

---

As #63912 has shown, there are places in BCL where files are being closed and very soon reopened (it's typically not obvious).

using (FileStream fs = new FileStream(destinationFileName, fMode, FileAccess.Write, FileShare.None, bufferSize: 0x1000, useAsync: false))
{
    using (Stream es = source.Open())
        es.CopyTo(fs);
} // the file is closed

File.SetLastWriteTime(destinationFileName, source.LastWriteTime.DateTime); // it's reopened

It causes two kinds of problems:

• AV and other software can open the file in the meantime, lock the access and hence make the re-opening code fail (ERROR_SHARING_VIOLATION on Windows)
• the perf is not ideal, as opening the files is expensive (especially on Unix where we perform more than 1 sys-call to open a file).

One of the potential solutions would be to use APIs that are accepting SafeFileHandle like #20234

Author:	adamsitnik
Assignees:	-
Labels:	area-System.IO
Milestone:	7.0.0