Bug 427149 - data corruption with mkzftree 1.0.6 release 3.2.1 on i386 FC5
data corruption with mkzftree 1.0.6 release 3.2.1 on i386 FC5
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: zisofs-tools (Show other bugs)
5
All Linux
low Severity medium
: ---
: ---
Assigned To: Harald Hoyer
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-01 09:09 EST by Gregoire Barbier
Modified: 2008-03-13 10:42 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-10 01:46:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gregoire Barbier 2008-01-01 09:09:54 EST
Description of problem:
I experience data corruption with mkzftree 1.0.6 release 3.2.1 on i386 FC5.
Some compressed files have their content slightly modified, with no error
message or warning. The only way to notice it is to diff the original
(uncompressed) tree with the mounted iso image.

Version-Release number of selected component (if applicable):
The corruption happen with this version on i386:

Name        : zisofs-tools                 Relocations: (not relocatable)
Version     : 1.0.6                             Vendor: Red Hat, Inc.
Release     : 3.2.1                         Build Date: dim 12 fév 2006 21:36:29

But not with same version, release 3.2.2 on x86_64 FC6.

On the 1.0.6-3.2.1 i386 FC5 not working, I've got zlib-1.2.3-1.2.1 and glibc-2.4-11.

On the 1.0.6-3.2.2 x86_64 FC6 working, I've got zlib-1.2.3-3 and glibc-2.5-3.

How reproducible:
It's hard to reproduce.
I've got 800 MB of personnal data where the bug appears, but I cannot manage to
have it reappear with a smaller subset of this data.
On that dataset, the same issue occurs each time I run mkzftree.

Steps to Reproduce:
1. mkzftree master master.z
2. mkizofs -o master.iso -r -z master.z
3. mount master.iso /mnt/foo -oloop
4. diff -r master /mnt/foo
  
Actual results:
many little differences such as:
---8<-----------------------
diff -r master/foo/bar/file,v /mnt/foo/foo/bar/file,v
10c10
< date  2002.06.14.18.37.38;    author gb;      state Exp;
---
> date  2002.06.14.20.45.12;    author gb;      state Exp;
31c31
< // Last update Wed Jun 12 09:30:35 2002 Gregoire Barbier
---
> // Last update Wed Jun 12 08:59:11 2002 Gregoire Barbier
34,35c34,35
< #ifndef   __SGBD2_H__
< #define   __SGBD2_H__
---
> #ifndef   __SGBD1_H__
> #define   __SGBD1_H__
---8<-----------------------


Expected results:
no differences !

Additional info:
I don't think it's coming from the kernel since I cross-tested the iso images.

I don't think I made a mistake since I reproduces the problem several times.

I think this can be a complicated interaction with zlib or glibc, since they
differ on the two machines.

I tried to use mkzftree from the Git source code. I rebuild version 1.0.6 and
last version (1.0.8). The issue still occurs with 1.0.6 but not with 1.0.8.
However the same 1.0.6 on my x86_64 FC6 works...

Unfortunatly "yum update zisofs-tools zlib glibc" does not propose to solve the
issue.
Comment 1 petrosyan 2008-03-10 01:46:26 EDT
Fedora Core 5 and Fedora Core 6 are no longer maintained. If you can reproduce
this bug in Fedora 7 or Fedora 8 please reopen this bug and assign it to the
corresponding Fedora version.
Comment 2 Gregoire Barbier 2008-03-13 10:42:59 EDT
Frankly, 3 months later I no longer have the data on which I encountered the bug. 

However I will download and recompile the 1.0.7 rpm of a F7 and see if I it
still occurs.

Thanks.

Note You need to log in before you can comment on or make changes to this bug.