Hide Forgot
Description of problem: * "jar -x ...": extracted files are sometimes longer than archived files. * '#define original_file file_put_into_the_archive' * in Detail: for every byte 0x0a in the original_file, the extracted file contains the bytes 0x0d, 0x0a . (1*) Version-Release number of selected component (if applicable): * gcc-3.2.2-5.src.rpm/fastJar/<files> compiled and linked with a Microsoft Visual Studio C++ -compiler and -linker version 6.0 . How reproducible: * depends on compiler and (1*) . Steps to Reproduce: 1. you have a compiler / operating-system that makes a difference between text- and binary-files 2. you have the byte 0x0a in the original file. Actual results: see (1*) Expected results: * the extraced and the original_file should have the same length and the same byte-sequence. Additional info: * see also line# 53 of gcc-3.2.2-5.src.rpm/.../fastJar/jartool.c, Revision 1.6 2001/07/04 18:33:53 . * at line# 264 of this file, the definition of "O_BINARY" is granted, even if not used in posix(?). * most (or all?) of the (file-)open(...) statements in the .../fastJar/<files> are written with the O_BINARY-flag. so if compiler or operating system distinguishes between binary and text-files, the files are opened in binary mode. * BUT: in function "extract_jar", line# 1458: create(...) is used for creating the extraced file instead of open; with the above compiler this results in open( ..., O_CREAT | O_TRUNC | O_RDWR | O_TEXT, ... ), the extacted file is created in text-mode, and according to the microsoft-operating-system for every LF=0x0a a CR=0x0d is prepended. * suggestion: replace there create(...) with open( ..., O_CREAT | O_TRUNC | O_RDWR | O_BINARY, ... ) ; exactly: " f_fd = open( (const char *)filename, O_CREAT | O_TRUNC | O_RDWR | O_BINARY, 00644 ); " * after applying this change to jartool.c, the compiled jar worked properly.
There is no O_BINARY nor O_TEXT on Linux, this report is misplaced. Guess you want to 1) test whether contemporary GCC (4.0.x or HEAD) behaves the same 2) if yes, report the bug to the correct place, i.e. http://gcc.gnu.org/bugzilla/