Bug 1092759
| Summary: | gzseek calls can incorrectly position the file. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | tsteven4 | ||||
| Component: | mingw-zlib | Assignee: | Richard W.M. Jones <rjones> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 19 | CC: | erik-fedora, fedora-mingw, fedora, lfarkas, rjones | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2015-01-19 12:28:48 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
If this is an upstream bug with zlib, then we need to wait for them to accept the patch and/or issue an updated package, which can then be added to the zlib & mingw-zlib packages in Fedora. The native executable does not show the problem because of conditional compilation and support for large files. It is only seen with the mingw* built executables which don't get created with large file support. If we could build mingw-zlib with large file support that would alleviate the issue. rhel 6 mingw32 works with the test case because it is built with a version of zlib before large file support was added to zlib. I'm still no closer to understanding what the action item is on this bug. There is no flag to enable large file support in ./configure --help. This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. |
Created attachment 890969 [details] zlib gzseek test case Description of problem: gzseek can incorrectly hit EOF, causing subsequent gzread calls to fail. Version-Release number of selected component (if applicable): mingw32-zlib-1.2.7-2.fc19.noarch How reproducible: 100% Steps to Reproduce: 1. unzip test case zlib_test2.zip provided. 2. run test2 script to compile the test case. 3. execute test case by running testz2.exe under windows. testz2.exe, zlib1.dll and test.data all need to be in the directory testz2.exe is executed from. Actual results: Got 0 Expected results: Got 4 Additional info: A possible patch with zlib 1.2.8 is listed below, although this might be a configuration problem. offset, which is of type z_off64_t, ends up being 32 bits as configured. --- gzlib.c 2013-03-24 23:47:59.000000000 -0600 +++ gzlib.patch.c 2014-04-27 15:34:38.496808069 -0600 @@ -393,7 +393,7 @@ /* if within raw area while reading, just go there */ if (state->mode == GZ_READ && state->how == COPY && state->x.pos + offset >= 0) { - ret = LSEEK(state->fd, offset - state->x.have, SEEK_CUR); + ret = LSEEK(state->fd, offset - (z_off64_t)state->x.have, SEEK_CUR); if (ret == -1) return -1; state->x.have = 0; I have reported this to zlib but haven't received any response yet.