Bugzilla will be upgraded to version 5.0 on December 2, 2018. The outage period for the upgrade will start at 0:00 UTC and have a duration of 12 hours
Bug 169174 - "(non-linux!!!) jar -x ...": extracted files are sometimes longer than original files.
"(non-linux!!!) jar -x ...": extracted files are sometimes longer than origin...
Product: Fedora Legacy
Classification: Retired
Component: libgcj (Show other bugs)
other Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2005-09-23 18:34 EDT by Thomas Bruecker
Modified: 2007-04-18 13:31 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-24 06:40:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Thomas Bruecker 2005-09-23 18:34:31 EDT
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 06:40:24 EDT
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.