Bug 169174 - "(non-linux!!!) jar -x ...": extracted files are sometimes longer than original files.
Summary: "(non-linux!!!) jar -x ...": extracted files are sometimes longer than origin...
Alias: None
Product: Fedora Legacy
Classification: Retired
Component: libgcj
Version: rhl9
Hardware: other
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-09-23 22:34 UTC by Thomas Bruecker
Modified: 2007-04-18 17:31 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2005-09-24 10:40:24 UTC

Attachments (Terms of Use)

Description Thomas Bruecker 2005-09-23 22:34:31 UTC
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

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
* 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.

Comment 1 Jakub Jelinek 2005-09-24 10:40:24 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.