[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-cpio] cpio: checksum error on 64-bit machines
From: |
Jim Castleberry |
Subject: |
[Bug-cpio] cpio: checksum error on 64-bit machines |
Date: |
Mon, 24 Oct 2005 13:14:15 -0600 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 |
Package: cpio
Version: 2.6-7
[ The above pseudo-headers are for the Debian email bug reporting system. ]
Vanilla cpio 2.6 sometimes writes bad crcs in the cpio header on 64-bit
machines. It seems to
show up only on some large files. The symptom is that the crc stored in the
file appears to
be shifted by one nibble, and fails the crc check on copy-out.
For example using the Openoffice 2.0 release from openoffice.org mirrors, eg
http://mirrors.ibiblio.org/pub/mirrors/openoffice/stable/2.0.0/OOo_2.0.0_LinuxIntel_install.tar.gz
$ uname -a Linux centos 2.6.9-11.ELsmp #1 SMP Wed Jun 8 16:59:12 CDT 2005
x86_64 x86_64 x86_64 GNU/Linux
$ cpio --version cpio (GNU cpio) 2.6
$ echo OOo_2.0.0_LinuxIntel_install.tar.gz |cpio -o --format=crc >test.cpio
207906 blocks
$ cpio -i --only-verify-crc <test.cpio
cpio: OOo_2.0.0_LinuxIntel_install.tar.gz: checksum error (0x32bf3b47,
should be 0x332bf3b4)
207906 blocks
$
Doing the same thing on a 32-bit i386 machine running the same software works
properly.
The only differences in the output file are in the c_maj, m_min, and c_chksum
fields of
the cpio header. All the other fields and the file data are the same and
correct.
The cpio-2.5 that comes with the current Redhat EL (cpio-2.5-8.RHEL4) exhibits
the
identical problem.
The bug was reported to Redhat by Michael J. Donahue in 1998 in cpio 2.4.2 on
Redhat 4.1
for alpha:
http://www.redhat.com/archives/axp-list/1998-March/msg00494.html
but apparently never addressed.
It was rediscovered by Tom Vier in 2001 2.4.2 on Debian and fixed by the debian
folks:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=100456
Looking at their patches for 2.4.2 at
http://ftp.debian.org/pool/main/c/cpio/cpio_2.4.2-39woody1.diff.gz
the fix was in function write_out_header():
@@ -60,7 +61,7 @@
file_hdr->c_gid, file_hdr->c_nlink, file_hdr->c_mtime,
file_hdr->c_filesize, file_hdr->c_dev_maj, file_hdr->c_dev_min,
file_hdr->c_rdev_maj, file_hdr->c_rdev_min, file_hdr->c_namesize,
- file_hdr->c_chksum);
+ file_hdr->c_chksum & 0xffffffff);
tape_buffered_write (ascii_header, out_des, 110L);
/* Write file name to output. */
I applied that same change to the vanilla 2.6 copyout.c and it fixes the
problem.
Patch is attached.
Note 1: The current Redhat ships cpio 2.5 with this defect. I've reported it
as bug 171649.
Note 2: Debian carried the patch over to their patches for cpio 2.5 but seems
to have
dropped it from their patches for 2.6. So I'd guess that their 2.6
has the same problem
too, though I haven't tried it. I'm Cc:'ing this email to the Debian
bug reporting
system.
--- cpio-2.6/src/copyout.c.orig 2004-10-14 03:14:03.000000000 -0600
+++ cpio-2.6/src/copyout.c 2005-10-24 12:28:43.832281758 -0600
@@ -311,7 +311,7 @@
file_hdr->c_gid, file_hdr->c_nlink, file_hdr->c_mtime,
file_hdr->c_filesize, file_hdr->c_dev_maj, file_hdr->c_dev_min,
file_hdr->c_rdev_maj, file_hdr->c_rdev_min, file_hdr->c_namesize,
- file_hdr->c_chksum);
+ file_hdr->c_chksum & 0xffffffff);
tape_buffered_write (ascii_header, out_des, 110L);
/* Write file name to output. */
- [Bug-cpio] cpio: checksum error on 64-bit machines,
Jim Castleberry <=
- Re: [Bug-cpio] cpio: checksum error on 64-bit machines, Jim Castleberry, 2005/10/26
- Re: [Bug-cpio] cpio: checksum error on 64-bit machines, Sergey Poznyakoff, 2005/10/27
- Re: [Bug-cpio] cpio: checksum error on 64-bit machines, Jim Castleberry, 2005/10/27
- Re: Bug#335580: [Bug-cpio] cpio: checksum error on 64-bit machines, Clint Adams, 2005/10/27
- Re: Bug#335580: [Bug-cpio] cpio: checksum error on 64-bit machines, Sergey Poznyakoff, 2005/10/28
- Re: Bug#335580: [Bug-cpio] cpio: checksum error on 64-bit machines, Clint Adams, 2005/10/30
- Re: Bug#335580: [Bug-cpio] cpio: checksum error on 64-bit machines, Sergey Poznyakoff, 2005/10/31