fixing ZipPackagePart.GetStreamCore crashes with NotSupportedException#40319
fixing ZipPackagePart.GetStreamCore crashes with NotSupportedException#40319stevenbrix merged 5 commits intomasterfrom
Conversation
ZipArchiveEntry only ever supports opening once when the backing archive is in Create mode, and the backing stream is non-seekable, so we shouldn't call SetLength in that case. You could still open an archive in Update mode then call part.GetStream(FileMode.Create), in which case we'll want this call to SetLength, so we only avoid this call when the backing Archive is in Create mode.
rladuca
left a comment
rladuca
left a comment
There was a problem hiding this comment.
Looks good to me. The only suggestion may be to directly write a test case for the open in update, then use a part in Create scenario.
I saw it had coverage in other test functions, but it didn't seem called out as a specific scenario unless I missed that in my scan of the other tests.
|
@stephentoub some tests are failing in UWP due to the file system restrictions, i tried following the instructions here to try and repro the failure locally but run into these errors:
Is there something else i need to do? |
|
@ViktorHofer, can you help @stevenbrix? |
|
Sure. You need to build from root for uap first : build -f uap. |
dotnet/corefx#40319) * fixing ZipPackagePart.GetStreamCore crashes with NotSupportedException ZipArchiveEntry only ever supports opening once when the backing archive is in Create mode, and the backing stream is non-seekable, so we shouldn't call SetLength in that case. You could still open an archive in Update mode then call part.GetStream(FileMode.Create), in which case we'll want this call to SetLength, so we only avoid this call when the backing Archive is in Create mode. * updating test to explicitly test the Update path for ZipPackage * skip UAP since we don't have access to the file system to create the .zip * undo accidental change to existing test * removing unnecessary variable Commit migrated from dotnet/corefx@8ac53e0
4 participants
The exception thrown here by
ZipPackagePartis dubious and unnecessary, and an unintended mistake from the initial port ofSystem.IO.Packagingfrom WindowsBase. ZipArchiveEntry only ever supports opening once when the backing archive is in Create mode, so the call to SetLength is unnecessary. You could still open an archive in Update mode then call part.GetStream(FileMode.Create), in which case we'll want this call to SetLength, so we only avoid this call when the backing Archive is in Create mode.Fixes #39816