Developers using FileStream find it to be high performance and robust

[benaadams]

(Note .CopyToAsync is pretty good; for certain combinations of flags)

P0

• Win32 FileStream turns async reads into sync reads Win32 FileStream turns async reads into sync reads #16341
• FileStream.FlushAsync ends up doing synchronous writes FileStream.FlushAsync ends up doing synchronous writes #27643
• Win32 FileStream will issue a seek on every ReadAsync and WriteAsync call Win32 FileStream will issue a seek on every ReadAsync call #16354
• FileStream.Windows useAsync WriteAsync calls blocking apis FileStream.Windows useAsync WriteAsync calls blocking apis #25905
• Avoid expensive GetFileInformationByHandleEx syscall if possible Avoid expensive GetFileInformationByHandleEx syscall if possible #49541
• Asynchronous random file access with FileStream Read vs ReadAsync in a loop / parallel (ReadAsync is slow) Asynchronous random file access with FileStream Read vs ReadAsync in a loop / parallel (ReadAsync is slow) #27047
• Reduce FileStream allocations Reduce FileStream allocations #49539

P1

• Avoid unnecessary allocations when using FileStream Avoid unnecessary allocations when using FileStream #15088
• FileStream file preallocation performance FileStream file preallocation performance #45946

P2

• Use PreallocatedOverlapped when internal FileStream buffer isn't being used on Windows Use PreallocatedOverlapped when internal FileStream buffer isn't being used on Windows #25074
• File.WriteAllTextAsync performance issues File.WriteAllTextAsync performance issues #23196
• Implement new FileStreamStrategy for Unix Implement new FileStreamStrategy for Unix #53809

Moved to Future

• File.ReadAllTextAsync not behaving asynchronously when called on inaccessible network files File.ReadAllTextAsync not behaving asynchronously when called on inaccessible network files #25314

Rosyln has their own workarounds for FileStream issues; and NuGet recently moved to mmap for better performance NuGet/NuGet.Client#3524

Edit by carlossanlop: To focus on the Async/Sync improvements, I'm removing 3 issues from the list that are separate from that topic.
_Edit by @adamsitnik: Proiorities

[danmoseley]

Thanks for collecting these into an “epic” 🙂 This is a candidate for some code debt work before 6.0 feature work starts.

[danmoseley]

@JeremyKuhne you've been a vocal advocate of improving FileStream in the past. Is there anything you want to add to this meta-issue?

[carlossanlop]

Thank you @benadams for compiling the list.

May I suggest to focus this epic specifically for improving sync/async in FileStream, which seems to be the main topic of most of those issues? If agreed, then these issues can be removed from the epic and addressed separately:

• FileStream.SetLength doesn't return file pointer to original value on failure #8307 FileStream.SetLength doesn't return file pointer to original value on failure.
• FileStream.Lock(Int64, Int64) failure on Linux - always uses 'F_WRLCK'. #29173 FileStream.Lock(Int64, Int64) failure on Linux - always uses F_WRLCK.
• FileStream.Flush(true) doesn't flush device buffer on macOS, while it does so on Windows #28444 FileStream.Flush(true) doesn't flush device buffer on macOS, while it does so on Windows.

[jeffhandley]

@stephentoub What do you think about #8307, #29173, and #28444 -- do you think those are standalone enough to treat separately from the bigger collection of issues? If so, we can go ahead and get started on those soon.

[stephentoub]

do you think those are standalone enough to treat separately from the bigger collection of issues?

Yes