[release/7.0] TarReader should dispose underlying stream if leaveOpen is false #80598
Conversation
…#79920) * Dispose underlying stream in TarReader.DisposeAsync() as well Same as dotnet#79899 * Consolidate duplicated WrappedStream test helpers to Common sources * Dispose stream passed to WrappedStream
* Dispose archive stream after the list of DataStreams * Add tests for TarReader.DisposeAsync properly disposing underlying stream
|
Tagging subscribers to this area: @dotnet/area-system-io Issue DetailsBackport of #79899, #79920, and #80572 to release/7.0 DetailsWe are not disposing the stream that is wrapped by TarReader even when specifically asked to dispose it with leaveOpen:false. Customer ImpactThis has a customer impact of potentially leaking resources without the user noticing it. as it manifested in our CI, #77012 shows how temporary files were piling up and out-of-disk-space errors happened due to the underlying FileStreams not being properly disposed. TestingUnit tests were added to verify that the underlying stream is properly disposed when the TarReader is disposed syncronously and asynchronously. RiskLow.
|
|
CI failures are timeout cancellations in browser (unrelated to this change). |
carlossanlop
added
Servicing-approved
|
Approved by Tactics via email (7.0.3). |
ghost
locked as resolved and limited conversation to collaborators
Backport of #79899, #79920, and #80572 to release/7.0
Details
We are not disposing the stream that is wrapped by TarReader even when specifically asked to dispose it with leaveOpen:false.
Customer Impact
This has a customer impact of potentially leaking resources without the user noticing it. as it manifested in our CI, #77012 shows how temporary files were piling up and out-of-disk-space errors happened due to the underlying FileStreams not being properly disposed.
Testing
Unit tests were added to verify that the underlying stream is properly disposed when the TarReader is disposed syncronously and asynchronously.
Risk
Low.