Reproduced with mc-4.6.1a-35.el5.x86_64 (i.e. different arch)

Reproduced with mc-4.6.1a-35.el5.i386 (32-bit arch). It's not a struct alignment issue.

Bingo. It's the new(er) compression algorithm in rpm's. "hexdump -vC CONTENTS.cpio" shows:

00000000  fd 37 7a 58 5a 00 00 0a  e1 fb 0c a1 02 00 21 01  |.7zXZ.........!.|
00000010  18 00 00 00 47 58 3a 43  e7 85 8a f0 00 5d 00 18  |....GX:C.....]..|
00000020  0d dd 04 63 83 21 5f 0f  54 31 c5 95 a2 fa 85 f8  |...c.!_.T1......|
00000030  79 3b c8 e6 9d a0 ee 9f  3e 59 ab dc e2 19 9e 3f  |y;......>Y.....?|
...

This is clearly a compressed file. RHEL5 has neither lzma nor xz (de)compression programs to deal with it...

mc just does not have corresponding support. I checked mc-4.6.1a-35 and mc-4.6.2-10 and I did not find any code to handle XZ archives. Therefore it simply misinterprets compressed .cpio as uncompressed.

Upstream code has such code:

    /* XZ compression magic */
    if (magic[0] == 0xFD
        && magic[1] == 0x37 && magic[2] == 0x7A && magic[3] == 0x58) {
        if (mc_read (fd, (char *) magic + 4, 2) == 2) {
            if (magic[4] == 0x5A && magic[5] == 0x00) {
                return COMPRESSION_XZ;
            }
        }
    }
...
static const struct edit_filters {
    const char *read, *write, *extension;
} all_filters[] = {
    { "xz -cd %s 2>&1",     "xz > %s",     ".xz" },
    { "lzma -cd %s 2>&1",   "lzma > %s",   ".lzma" },
    { "bzip2 -cd %s 2>&1",  "bzip2 > %s",  ".bz2" },
    { "gzip -cd %s 2>&1",   "gzip > %s",   ".gz"  },
    { "gzip -cd %s 2>&1",   "gzip > %s",   ".Z"   }
};

Created attachment 364917 [details]
Proposed fix

This fix at least will make mc to not abort, but just inform the user that cpio file seems to be corrupted.

How about we rather enhance mc to understand xz in a future RHEL 5 minor update?

xz support and "do not crash horribly on a bad .cpio file" bug are unrelated problems. This patch fixes the second problem. Let's decide whether we want this fix. Meanwhile I'll look into adding xz support.

It's not an mc bug!
mc just uses rpm2cpio, and on RHEL5.5 rpm2cpio does not unpack .cpio, it extracts it still XZ-packed:

# rpm2cpio kernel-debuginfo-2.6.33.2-68.fc13.i686.rpm >z.cpio
# hexdump -C z.cpio | head
00000000  fd 37 7a 58 5a 00 00 0a  e1 fb 0c a1 02 00 21 01  |.7zXZ.........!.|
00000010  0e 00 00 00 04 50 48 36  e7 cb b5 f0 00 5d 00 18  |.....PH6.....]..|
00000020  0d dd 04 62 32 88 43 6d  31 bd 26 74 38 9a 03 54  |...b2.Cm1.&t8..T|
00000030  68 41 ce be ca 1c 3e 04  9c c7 81 04 7f de b3 da  |hA....>.........|
00000040  47 36 23 44 d3 05 df 28  18 16 cc aa d7 3a 56 c3  |G6#D...(.....:V.|
00000050  60 e7 bb 00 99 24 45 01  ed 3c b4 34 79 23 94 77  |`....$E..<.4y#.w|
00000060  d2 08 c4 01 37 33 08 0c  f1 1c 95 6d 37 5a 76 a1  |....73.....m7Zv.|
00000070  04 cd e7 dc 30 6a 8a 21  0c 14 e4 ca a8 a0 01 c1  |....0j.!........|
00000080  b3 55 ac 7c f4 4a 7f de  c7 3f 1e ff 81 91 21 ef  |.U.|.J...?....!.|
00000090  ff 91 18 03 45 1c 5f 46  f4 33 dc 31 c4 27 e5 43  |....E._F.3.1.'.C|

On F12, for example, extracted .cpio is not packed.

Even though it is not an mc bug, adding xz decompression support still makes it possible to handle xz-compressed .rpm's.

Created attachment 409756 [details]
Patch to add xz decompression support

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

Hi,
Is there a workaround or a fixed rpm2cpio available for RHEL 5.x somewhere ?

Thanks.

Alok, see bug #602423, there is a shell script rpm2cpio.sh which can be used instead of rpm2cpio. The problem with it is it relies on file utility to detect xz compression which doesn't work with file from rhel5.5, so you have to apply the patch from me.

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

This request was erroneously denied for the current release of
Red Hat Enterprise Linux.  The error has been fixed and this
request has been re-proposed for the current release.

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

I don't think this issue is critical enough to be fixed in RHEL5.