dotnet/runtime
Auf GitHub ansehenIdentify places where file handles are closed and very soon reopened again
Open
#64.288 geöffnet am 25. Jan. 2022
area-System.IOhelp wanted
Repository-Metriken
- Stars
- (17.886 Stars)
- PR-Merge-Metriken
- (Durchschn. Merge 12T 11h) (661 gemergte PRs in 30 T)
Beschreibung
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