GZipStream.Read(byte[],int,int) return a Incorrect length.

[DebugST]

Description

nLen = gs.Read(byTemp, 0, byTemp.Length);
The nLen != byTemp.Length ,byTemp.Length = 275968 but nLen = 11854.
In .Net Framework the nLen = 275968, but in Standard and Net6 also get 11854. And the Stream is not at the end.
If the data of the specified length cannot be read when the Stream is not over, what's the point of passing in a specified length?

Reproduction Steps

none

Expected behavior

none

Actual behavior

none

Regression?

in Framework it's ok.

Known Workarounds

I think the specified length should be read and returned while the Stream is not over yet.
Although I can get around this by reading in a loop. But since the Read function specifies the length to be read, why can't it be read according to the specified length? Otherwise, just Read(byte[]) will do.

Configuration

No response

Other information

No response

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[meziantou]

This is a documented breaking change in .NET 6: Partial and zero-byte reads in DeflateStream, GZipStream, and CryptoStream

[ghost]

Tagging subscribers to this area: @dotnet/area-system-io-compression
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

nLen = gs.Read(byTemp, 0, byTemp.Length);
The nLen != byTemp.Length ,byTemp.Length = 275968 but nLen = 11854.
In .Net Framework the nLen = 275968, but in Standard and Net6 also get 11854. And the Stream is not at the end.
If the data of the specified length cannot be read when the Stream is not over, what's the point of passing in a specified length?

Reproduction Steps

none

Expected behavior

none

Actual behavior

none

Regression?

in Framework it's ok.

Known Workarounds

I think the specified length should be read and returned while the Stream is not over yet.
Although I can get around this by reading in a loop. But since the Read function specifies the length to be read, why can't it be read according to the specified length? Otherwise, just Read(byte[]) will do.

Configuration

No response

Other information

No response

Author:	DebugST
Assignees:	-
Labels:	area-System.IO.Compression, untriaged
Milestone:	-

[huoyaoyuan]

By contract, Stream.Read can fill any positive number of bytes. There's no guarantee to fulfill the buffer.

To fulfill, you can use the newly introduced ReadExactly in .NET 7.

what's the point of passing in a specified length?

The length parameter is associated with the buffer. The buffer may be allocated in advance and only a part of it is meant to be used.

[DebugST]

By contract, Stream.Read can fill any positive number of bytes. There's no guarantee to fulfill the buffer.

To fulfill, you can use the newly introduced ReadExactly in .NET 7.

what's the point of passing in a specified length?

The length parameter is associated with the buffer. The buffer may be allocated in advance and only a part of it is meant to be used.

In fact, I personally think that if you make some changes to the function, you can add a new function Read(byte[]), but directly modifying Read(byte[], int, int) leads to compatibility problems. Because Read(byte[], int, int) works correctly on FrameWork. When I ported to Core or Standard. . caused compatibility issues. now I need to change some code for Core or Standard.
If the stream does not end, it should read the length I specified, if not, just design the function as [int Read(byte[])].
Of course this is my personal understanding.

[adamsitnik]

Hi @DebugST

As @meziantou has pointed out, we have introduced this breaking change in .NET 6 and this was done on purpose because since .NET 1.0 Stream.Read was not promising to read exactly n bytes, but the bytes available and return their count.

As pointed by @huoyaoyuan you can use the new ReadExactly methods added to Stream in .NET 7 preview 5: dotnet/core#7441 (comment)

If your code is targeting .NET Framework, .NET Standard and .NET you can just copy-paste the implementation from here:

#if !NET6_0_OR_GREATER // won't be included in your .NET 7 builds
namespace System.IO
{
    public static class StreamExtensions
    {
        public static void ReadExactly(this Stream stream, byte[] buffer, int offset, int count)
        {
            // the copied code goes here
        }
    }
}
#endif

Since this was done on purpose and we don't intend to change it, I am going to close the issue.

Thanks!

[DebugST]

Hi @DebugST

As @meziantou has pointed out, we have introduced this breaking change in .NET 6 and this was done on purpose because since .NET 1.0 Stream.Read was not promising to read exactly n bytes, but the bytes available and return their count.

As pointed by @huoyaoyuan you can use the new ReadExactly methods added to Stream in .NET 7 preview 5: dotnet/core#7441 (comment)

If your code is targeting .NET Framework, .NET Standard and .NET you can just copy-paste the implementation from here:

#if !NET6_0_OR_GREATER // won't be included in your .NET 7 builds
namespace System.IO
{
    public static class StreamExtensions
    {
        public static void ReadExactly(this Stream stream, byte[] buffer, int offset, int count)
        {
            // the copied code goes here
        }
    }
}
#endif

Since this was done on purpose and we don't intend to change it, I am going to close the issue.

Thanks!

Tks..i had changed my code.