dotnet/runtime
View on GitHubIdentify places where file handles are closed and very soon reopened again
Open
#64,288 opened on Jan 25, 2022
area-System.IOhelp wanted
Repository metrics
- Stars
- (17,886 stars)
- PR merge metrics
- (Avg merge 12d 11h) (661 merged PRs in 30d)
Description
As https://github.com/dotnet/runtime/pull/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_VIOLATIONon 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 https://github.com/dotnet/runtime/issues/20234