[ 
https://issues.apache.org/jira/browse/COMPRESS-584?focusedWorklogId=633326&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-633326
 ]

ASF GitHub Bot logged work on COMPRESS-584:
-------------------------------------------

                Author: ASF GitHub Bot
            Created on: 04/Aug/21 07:13
            Start Date: 04/Aug/21 07:13
    Worklog Time Spent: 10m 
      Work Description: PeterAlfredLee commented on a change in pull request 
#214:
URL: https://github.com/apache/commons-compress/pull/214#discussion_r682349198



##########
File path: src/test/java/org/apache/commons/compress/utils/IOUtilsTest.java
##########
@@ -148,6 +148,25 @@ public void 
readRangeFromChannelDoesntReadMoreThanAskedFor() throws IOException
         }
     }
 
+    @Test
+    public void 
readRangeFromChannelDoesntReadMoreThanAskedForWhenItGotLessInFirstReadCall() 
throws IOException {
+        try (ReadableByteChannel in = new SeekableInMemoryByteChannel(new 
byte[] { 1, 2, 3, 4, 5 }) {
+            @Override
+            public int read(ByteBuffer buf) throws IOException {
+                // Read max 3 bytes at a time
+                ByteBuffer temp = ByteBuffer.allocate(Math.min(3, 
buf.remaining()));

Review comment:
       I think we can have a `final` here.
   Even through this is just a test, it's always appreciated if `final` is 
always used if possible.

##########
File path: src/test/java/org/apache/commons/compress/utils/IOUtilsTest.java
##########
@@ -148,6 +148,25 @@ public void 
readRangeFromChannelDoesntReadMoreThanAskedFor() throws IOException
         }
     }
 
+    @Test
+    public void 
readRangeFromChannelDoesntReadMoreThanAskedForWhenItGotLessInFirstReadCall() 
throws IOException {
+        try (ReadableByteChannel in = new SeekableInMemoryByteChannel(new 
byte[] { 1, 2, 3, 4, 5 }) {
+            @Override
+            public int read(ByteBuffer buf) throws IOException {
+                // Read max 3 bytes at a time
+                ByteBuffer temp = ByteBuffer.allocate(Math.min(3, 
buf.remaining()));
+                int read = super.read(temp);
+                if (read > 0) {
+                    buf.put(temp.array(), 0, read);
+                }
+                return read;
+            }
+        }) {
+            byte[] read = IOUtils.readRange(in, 4);

Review comment:
       Same as above




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
-------------------

    Worklog Id:     (was: 633326)
    Time Spent: 40m  (was: 0.5h)

> IOUtils.readRange() can read more from a channel than asked for
> ---------------------------------------------------------------
>
>                 Key: COMPRESS-584
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-584
>             Project: Commons Compress
>          Issue Type: Bug
>          Components: Archivers
>    Affects Versions: 1.21
>            Reporter: Matthijs Laan
>            Priority: Major
>          Time Spent: 40m
>  Remaining Estimate: 0h
>
> When {{IOUtils.readRange(ReadableByteChannel,int)}} gets less than the number 
> of bytes asked for in the first read call it does not reduce the buffer size 
> for the next read call and may read more than asked for.
> This situation is rare when using a {{FileChannel}} but I wrote a 
> {{SeekableByteChannel}} backed by a URI using HTTP range requests and reading 
> from a socket can often return less bytes than asked for. When I used this 
> channel to read a {{ZipFile}} it only read the ZIP central directory 
> partially sometimes because {{IOUtils.readRange()}} called from 
> {{ZipFile.readCentralDirectoryEntry()}} read more bytes than asked for and it 
> stopped parsing directory entries.
> Fix: [https://github.com/apache/commons-compress/pull/214]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to