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.