I am porting an application which uses zlib's gzseek quite extensively to do pseudo- random access of the content of large gz'ed files, in the same manner of some's use of posix's lseek.
On small test data, it works correctly on wine. (identical result as linux). On production data - a large 9GB file - it gives gabbage. I thought it is 32-bit file access problem, until I check the return value of gzseek explicitly. It is supposed to return the same value as input on success, -1 on error.
On wine, it does neither, *occasionally*! I found that a first gzseek works correctly, then a 2nd fails. It does not fails with a -1, but fails with a large bogus value. Currently I am working around this strange behavior by closing the file and re-opening until it gets a correct offset. The large bogus value increases gradually and wrap around about 8-10 such repeated set of gzseek calls.
Anybody has any suggestion why gzseek would behave badly *intermittently* in wine? I assume it works correctly in windows - hardly to think that it doesn't work, considering how old zlib is and the vast number of windows application which uses zlib.
On a separate note, the application seems extraordinary slow in wine (again I haven't tried in windows..) - even when it works correctly without the work-around, it is hundreds of times slower in wine than in linux.
considering how old zlib is and the vast number of windows application which uses zlib
Given how many people duplicate the effort to package zlib, the fact that they're rarely updated, and the sort of problems gnulib exists to work around, it would not surprise me if your particular zlib binary is broken somehow.
-
Hin-Tak Leung -
Vincent Povirk