dotnet/runtime
Vedi su GitHubIdentify places where file handles are closed and very soon reopened again
Open
#64.288 aperta il 25 gen 2022
area-System.IOhelp wanted
Metriche repository
- Star
- (17.886 star)
- Metriche merge PR
- (Merge medio 12g 11h) (661 PR mergiate in 30 g)
Descrizione
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