Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcvax!ukc!servax0!peter
From: peter@essex.ac.uk	 (Allott P)
Newsgroups: comp.bugs.4bsd
Subject: cpio - segmentation violation
Keywords: cpio
Message-ID: <1120@servax0.essex.ac.uk>
Date: 14 Jun 89 16:20:18 GMT
Sender: news@servax0.essex.ac.uk
Organization: University of Essex, Colchester, UK
Lines: 35

We have observed a problem with cpio getting a segmentation violation when
reading a -c (character) tape.

The problem is that some users have files on their areas with a uid of -2.
This is probably due to some sort of nfs problem, be that as it may.

When an attempt is made to read such a tape we get segmentation violations.
What has happened is that when cpio attempts to convert the -2 to six octal
characters with an sprintf in bintochar, more than six digits are generated
by the %.6ho format string. The result is that the header information is
misaligned and incomplete, and this causes chaos on read back.

I would believe that if we mask the uid (and gid for that matter) to 16 bits
in the int generated in the call to sprintf within bintochar all should
be well.  (I have not tested this yet!)

I don't think tapes written by the rogue version of cpio (i.e. the version
everybody has got) are readable.

I wonder if I have not seen this sort of problem being blamed on exabytes
some where in the news system?

I give below the correct routine, It's no use to anyone without sources
so I don't think I'm breaking copyright.
----------------------------------------------------------------------------
bintochar(t)		/* ASCII header write */
long t;
{
      sprintf(Chdr,"%.6o%.6ho%.6ho%.6ho%.6ho%.6ho%.6ho%.6ho%.11lo%.6ho%.11lo%s",
		MAGIC,Statb.st_dev & 00000177777,Statb.st_ino,Statb.st_mode,
		Statb.st_uid & 00000177777, Statb.st_gid & 00000177777,
		Statb.st_nlink, Statb.st_rdev & 00000177777 ,Statb.st_mtime,
		(short)strlen(Hdr.h_name)+1,t,Hdr.h_name);
}
============================================================================