Mail Archives: cygwin/2003/03/14/14:04:58
Mike,
First of all, a very simple test does not confirm the symptom you're
seeing. If you'd like to send me (off-list) a BZip2-compressed TAR
archive containing test files and the series of fastjar invocations
that produce the problem on your system, I'd be willing to try to
confirm it that way.
Secondly, it's an odd problem, consider the following:
The obvious hypothesis is that this is a text / binary problem.
However, a quick look at the fastjar code shows that O_BINARY is used
uniformly in jartool.c (but not in jargrep.c, which is probably a problem):
% egrep 'open\>[ ]*\(' *.[ch]
jargrep.c: if((fd = open(jarfile, O_RDONLY)) == -1) {
jartool.c: jarfd = open(jarfile, O_CREAT | O_BINARY | O_WRONLY | O_TRUNC,
jartool.c: jarfd = open(jarfile, O_RDONLY | O_BINARY);
jartool.c: if((jarfd = open(jarfile, O_RDWR | O_BINARY)) < 0) {
jartool.c: mfd = open(mf_name, O_RDONLY | O_BINARY);
jartool.c: add_fd = open(file, O_RDONLY | O_BINARY);
Surely the O_BINARY option to the open(2) call overrides a text mount
or the CYGWIN=nobinmode option, so I don't see how this could be the
problem. I can find no mention of automode in the local configuration /
make files (those in the fastjar directory itself).
So I guess it must be something else.
One thing I'm noticing is that among the include files in /usr/include,
there are disparate definitions of O_BINARY. Presumably this is not an
error, but rather a difference in the implementation or operation of
Windows' / MinGW's and Cygwin's open options:
% egrep -R O_BINARY /usr/include
/usr/include/mingw/fcntl.h:#define _O_BINARY 0x8000 /* Input
and output is not translated. */
/usr/include/mingw/fcntl.h:#define _O_RAW _O_BINARY
/usr/include/mingw/fcntl.h:#define O_BINARY _O_BINARY
/usr/include/sys/fcntl.h:#define O_BINARY _FBINARY
/usr/include/sys/fcntl.h:#define _O_BINARY O_BINARY
/usr/include/sys/fcntl.h:#define _O_RAW O_BINARY
% egrep -R _FBINARY /usr/include
/usr/include/sys/fcntl.h:#define _FBINARY 0x10000
/usr/include/sys/fcntl.h:#define O_BINARY _FBINARY
There were O_BINARY matches from /usr/include/apache,
/usr/include/kpathsea and /usr/include/postresql but I'll assume those
are irrelevant. That leaves the mingw/ and sys/ directories. Since
jartool is a Cygwin program, it should be using sys/fcntl.
% egrep '^[ ]*#[ ]*include\>' jartool.{h,c}
jartool.h:#include "config.h"
jartool.c:#include "config.h"
jartool.c:#include <zlib.h>
jartool.c:#include <stdlib.h>
jartool.c:#include <unistd.h>
jartool.c:#include <stdio.h>
jartool.c:#include <sys/stat.h>
jartool.c:#include <sys/types.h>
jartool.c:#include <sys/param.h>
jartool.c:#include <dirent.h>
jartool.c:#include <fcntl.h>
jartool.c:#include <string.h>
jartool.c:#include <errno.h>
jartool.c:#include <sys/time.h>
jartool.c:#include <time.h>
jartool.c:#include <getopt.h>
jartool.c:#include "jartool.h"
jartool.c:#include "zipfile.h"
jartool.c:#include "dostime.h"
jartool.c:#include "pushback.h"
jartool.c:#include "compress.h"
It looks OK, but without configuring the whole shebang to find out
exactly what -I (cap I, as in include) or -l (small l, as in library),
binmode.o / automode.o, -D, etc. options are in effect it's impossible
to tell for sure.
I'm afraid I'm not that ambitious.
Randall Schulz
P.S. Mike, you need to get your shift key fixed. It appears to be
malfunctioning.
At 10:14 2003-03-14, Mike Andrews wrote:
>hi there, i've noticed that this cygwin-distributed application
>("/bin/jar.exe") often corrupts files it archives, especially
>binaries, the evidence mainly being that md5sums change after the
>archiving/dearchiving operation. text files also sometimes get
>corrupted, but so far i've only seen ignorable whitespace corruption.
>thus, i've switched to sun microsystem's j2sdk-1.4 jar.exe program
>until this issue gets resolved. thanks so much -- mike andrews
>
>mike andrews
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -