Sometime between GNU cpio 2.6 and GNU cpio 2.8, the
code to read tar headers was rewritten.  After this,
the parsing of numbers in tar headers now rejects
perfectly valid archives.

In particular, the traditional storage for the
"mode" field terminated the number with a space
followed by a NULL (see, for example, the 2.10 BSD
tar.5 manual page in the manpage browser at
www.freebsd.com).  The subsequent POSIX specs
for ustar permit numeric fields to be terminated
with any combination of spaces or nulls.

The key culprit is the from_ascii() routine in
copyin.c, which returns an error unless the number
completely fills the field or has null termination.
For cpio formats, of course, the field should be filled;
tar formats have different requirements.  It was probably
a mistake to try to use the same number-parsing
routine for both.

This was first noticed on FreeBSD but has since been
verified on other platforms with both GNU cpio 2.8 and
GNU cpio 2.9.  There's further discussion in the
mailing list thread that starts at:

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=42577+0+current/freebsd-current