Commons Compress
  1. Commons Compress
  2. COMPRESS-270

TarArchiveInputStream fails to read PAX header from InputStream

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.8
    • Fix Version/s: 1.8.1
    • Component/s: Archivers
    • Labels:

      Description

      We have a scenario with a "slow" InputStream and are facing IOExceptions with TarArchiveEntry#getNextTarEntry().

      If the InputStream does not deliver fast enough, TarArchiveEntry#parsePaxHeaders(InputStream i) fails at this location:

      TarArchiveInputStream.java
      // Get rest of entry
      byte[] rest = new byte[len - read];
      int got = i.read(rest);
      if (got != len - read){
      	throw new IOException("Failed to read "
      		+ "Paxheader. Expected "
      		+ (len - read)
      		+ " bytes, read "
      		+ got);
      }
      

      We would suggest to change the code to something like this:

      TarArchiveInputStream.java
      // Get rest of entry
      byte[] rest = new byte[len - read];
      int got = 0;
      while((ch = i.read()) != -1) {
      	rest[got] = (byte) ch;
      	got++;
      	if(got == len - read) {
      		break;
      	}
      }
      if (got != len - read){
      	throw new IOException("Failed to read "
      		+ "Paxheader. Expected "
      		+ (len - read)
      		+ " bytes, read "
      		+ got);
      }
      

      This would make sure, that it gets all bytes of the PAX header value.

        Activity

        Hide
        Stefan Bodewig added a comment -

        there is IOUtils#readFully and I had hoped I had caught all places where we expected read to succeed by now. Obviously not. Sorry.

        This case is fixed with svn revision 1582594 but I'll leave this issue open as a reminder to scan through the code base once again.

        Show
        Stefan Bodewig added a comment - there is IOUtils#readFully and I had hoped I had caught all places where we expected read to succeed by now. Obviously not. Sorry. This case is fixed with svn revision 1582594 but I'll leave this issue open as a reminder to scan through the code base once again.
        Hide
        Stefan Bodewig added a comment -

        found two more cases inside the snappy and the ar package

        Show
        Stefan Bodewig added a comment - found two more cases inside the snappy and the ar package

          People

          • Assignee:
            Unassigned
            Reporter:
            Patrik Burkhalter
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development