-
Bug
-
Resolution: Fixed
-
P4
-
1.4.0, 1.4.1, 6
-
b97
-
generic, x86, sparc
-
generic, linux, solaris_8
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2200210 | 6u23 | Dmitriy Samersoff | P2 | Resolved | Fixed | b02 |
JDK-2199460 | 6u22-rev | Dmitriy Samersoff | P2 | Closed | Fixed | b05 |
JDK-2192186 | 6u21-rev | Dmitriy Samersoff | P2 | Closed | Fixed | b08 |
Name: nt126004 Date: 05/24/2002
FULL PRODUCT VERSION :
java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)
FULL OPERATING SYSTEM VERSION :Linux skipper 2.4.2-2 #1 Sun
Apr 8 20:41:30 EDT 2001 i686 unknown
ADDITIONAL OPERATING SYSTEMS : Win2000, WinXP
A DESCRIPTION OF THE PROBLEM :
The "read" method from GZIPInputStream is returning -1
before the true actual end of the file. Some .gz files work
just fine and others do not.
JRE 1.2 and 1.3 also do not work.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. java wc.utils.test.test
2. ls -l test.log
3. Results: 24166 test.log
Size of the test.log should be 6,124,669 bytes.
EXPECTED VERSUS ACTUAL BEHAVIOR :
I expected the full decompressed file to be extracted from
the .gz file. Using the command line unix program "gzip"
the total size is 6,124,669 bytes and is decompressed just
fine.
Only 28,672 bytes were extracted before the
GZIPInputStream.read method returns a -1.
ERROR MESSAGES/STACK TRACES THAT OCCUR :
GZIPInputStream.read simply returns -1 too soon.
This bug can be reproduced occasionally.
---------- BEGIN SOURCE ----------
package wc.utils.test;
import java.io.*;
import java.net.*;
import java.util.zip.*;
public class test
{
final private static int BUFFER_SIZE = 4096;
public static void main(String args[] )
{
byte[] byteBuffer = new byte [ BUFFER_SIZE ];
int bytesRead = -1;
try
{
FileOutputStream fileOut = new FileOutputStream("output.txt");
FileInputStream fileInput = new FileInputStream
( "test.log" );
GZIPInputStream fileGzipInput = new GZIPInputStream ( fileInput,
BUFFER_SIZE );
bytesRead = fileGzipInput.read ( byteBuffer, 0, BUFFER_SIZE );
while ( bytesRead >= 0 )
{
fileOut.write(byteBuffer, 0, bytesRead);
byteBuffer = new byte [ BUFFER_SIZE ];
bytesRead = fileGzipInput.read ( byteBuffer, 0, BUFFER_SIZE );
}
}
catch (Exception e)
{
System.err.println ( e.toString() );
e.printStackTrace ( System.err );
}
} // end of public static void main()
} // end of public class test
---------- END SOURCE ----------
CUSTOMER WORKAROUND :
Absolutely none.
(Review ID: 146741)
======================================================================
Name: nt126004 Date: 03/04/2003
FULL PRODUCT VERSION :
java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)
FULL OPERATING SYSTEM VERSION :SunOS dev1 5.8 Generic_108528-15 sun4u sparc SUNW,Sun-Fire-480R
ADDITIONAL OPERATING SYSTEMS :
A DESCRIPTION OF THE PROBLEM :
When reading in the contents of a concatenated gzip file (one comprised of more than one gzip file) GZIPInputStream returns eof when it encounters the first gzip trailer. When using GZIPInputStream on other platforms this problem does not occur. The man page for gzip specifies that gunzip allows for concatenated files, though I am not sure which behavior was intended for the Solaris JDK.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Create a concatenated gzip file, e.g. cat file1.gz file2.gz > file3.gz
or use NIO channels.
2. Read in the new file using FileInputStream > GZIPInputStream > InputStreamReader > LineNumberReader
EXPECTED VERSUS ACTUAL BEHAVIOR :
- FileInputStream reports more data available, while GZIPInputStream has closed after hitting first file trailer.
- Trying to open a new GZIPInputStream on the FileInputStream results in a "not in GZIP format" error
ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.io.IOException: Not in GZIP format
2003/02/21 16:32:34.945 NULL ERROR WileyWebLo + at java.util.zip.GZIPInputStream.readHeader(GZIPInputStream.java:131)
2003/02/21 16:32:34.945 NULL ERROR WileyWebLo + at java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:58)
2003/02/21 16:32:34.945 NULL ERROR WileyWebLo + at java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:68)
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
/**
* TestGZIPIS
*
* Description
*
* Date: Feb 24, 2003
*
* @author johnclay
* @version $Id$
*
*/
import java.io.LineNumberReader;
import java.io.InputStreamReader;
import java.io.FileInputStream;
import java.util.zip.GZIPInputStream;
public class TestGZIPIS {
public static void main (String[] args) {
//send in file path as arg[0]
FileInputStream fis = new FileInputStream(args[0]);
GZIPInputStream gzis = new GZIPInputStream(fis);
InputStreamReader isr = new InputStreamReader(gzis);
LineNumberReader lnr = new LineNumberReader(isr);
String line;
while((line = lnr.readLine()) != null) {
System.out.println(line);
}
}
}
---------- END SOURCE ----------
CUSTOMER WORKAROUND :
have tried numerous workarounds including various tests for real end of file, opening new streams, marking, reseting, filtering, etc.
(Review ID: 181706)
======================================================================
FULL PRODUCT VERSION :
java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)
FULL OPERATING SYSTEM VERSION :Linux skipper 2.4.2-2 #1 Sun
Apr 8 20:41:30 EDT 2001 i686 unknown
ADDITIONAL OPERATING SYSTEMS : Win2000, WinXP
A DESCRIPTION OF THE PROBLEM :
The "read" method from GZIPInputStream is returning -1
before the true actual end of the file. Some .gz files work
just fine and others do not.
JRE 1.2 and 1.3 also do not work.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. java wc.utils.test.test
2. ls -l test.log
3. Results: 24166 test.log
Size of the test.log should be 6,124,669 bytes.
EXPECTED VERSUS ACTUAL BEHAVIOR :
I expected the full decompressed file to be extracted from
the .gz file. Using the command line unix program "gzip"
the total size is 6,124,669 bytes and is decompressed just
fine.
Only 28,672 bytes were extracted before the
GZIPInputStream.read method returns a -1.
ERROR MESSAGES/STACK TRACES THAT OCCUR :
GZIPInputStream.read simply returns -1 too soon.
This bug can be reproduced occasionally.
---------- BEGIN SOURCE ----------
package wc.utils.test;
import java.io.*;
import java.net.*;
import java.util.zip.*;
public class test
{
final private static int BUFFER_SIZE = 4096;
public static void main(String args[] )
{
byte[] byteBuffer = new byte [ BUFFER_SIZE ];
int bytesRead = -1;
try
{
FileOutputStream fileOut = new FileOutputStream("output.txt");
FileInputStream fileInput = new FileInputStream
( "test.log" );
GZIPInputStream fileGzipInput = new GZIPInputStream ( fileInput,
BUFFER_SIZE );
bytesRead = fileGzipInput.read ( byteBuffer, 0, BUFFER_SIZE );
while ( bytesRead >= 0 )
{
fileOut.write(byteBuffer, 0, bytesRead);
byteBuffer = new byte [ BUFFER_SIZE ];
bytesRead = fileGzipInput.read ( byteBuffer, 0, BUFFER_SIZE );
}
}
catch (Exception e)
{
System.err.println ( e.toString() );
e.printStackTrace ( System.err );
}
} // end of public static void main()
} // end of public class test
---------- END SOURCE ----------
CUSTOMER WORKAROUND :
Absolutely none.
(Review ID: 146741)
======================================================================
Name: nt126004 Date: 03/04/2003
FULL PRODUCT VERSION :
java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)
FULL OPERATING SYSTEM VERSION :SunOS dev1 5.8 Generic_108528-15 sun4u sparc SUNW,Sun-Fire-480R
ADDITIONAL OPERATING SYSTEMS :
A DESCRIPTION OF THE PROBLEM :
When reading in the contents of a concatenated gzip file (one comprised of more than one gzip file) GZIPInputStream returns eof when it encounters the first gzip trailer. When using GZIPInputStream on other platforms this problem does not occur. The man page for gzip specifies that gunzip allows for concatenated files, though I am not sure which behavior was intended for the Solaris JDK.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Create a concatenated gzip file, e.g. cat file1.gz file2.gz > file3.gz
or use NIO channels.
2. Read in the new file using FileInputStream > GZIPInputStream > InputStreamReader > LineNumberReader
EXPECTED VERSUS ACTUAL BEHAVIOR :
- FileInputStream reports more data available, while GZIPInputStream has closed after hitting first file trailer.
- Trying to open a new GZIPInputStream on the FileInputStream results in a "not in GZIP format" error
ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.io.IOException: Not in GZIP format
2003/02/21 16:32:34.945 NULL ERROR WileyWebLo + at java.util.zip.GZIPInputStream.readHeader(GZIPInputStream.java:131)
2003/02/21 16:32:34.945 NULL ERROR WileyWebLo + at java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:58)
2003/02/21 16:32:34.945 NULL ERROR WileyWebLo + at java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:68)
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
/**
* TestGZIPIS
*
* Description
*
* Date: Feb 24, 2003
*
* @author johnclay
* @version $Id$
*
*/
import java.io.LineNumberReader;
import java.io.InputStreamReader;
import java.io.FileInputStream;
import java.util.zip.GZIPInputStream;
public class TestGZIPIS {
public static void main (String[] args) {
//send in file path as arg[0]
FileInputStream fis = new FileInputStream(args[0]);
GZIPInputStream gzis = new GZIPInputStream(fis);
InputStreamReader isr = new InputStreamReader(gzis);
LineNumberReader lnr = new LineNumberReader(isr);
String line;
while((line = lnr.readLine()) != null) {
System.out.println(line);
}
}
}
---------- END SOURCE ----------
CUSTOMER WORKAROUND :
have tried numerous workarounds including various tests for real end of file, opening new streams, marking, reseting, filtering, etc.
(Review ID: 181706)
======================================================================
- backported by
-
JDK-2200210 GZIPInputStream fails to read concatenated .gz files
-
- Resolved
-
-
JDK-2192186 GZIPInputStream fails to read concatenated .gz files
-
- Closed
-
-
JDK-2199460 GZIPInputStream fails to read concatenated .gz files
-
- Closed
-
- duplicates
-
JDK-4763158 Need to document current limitations of java.util.GZIPInputStream
-
- Closed
-
- relates to
-
JDK-8322256 Define and document GZIPInputStream concatenated stream semantics
-
- In Progress
-
-
JDK-7021870 GzipInputStream closes underlying stream during reading
-
- Closed
-
(1 relates to)