[comp.bugs.4bsd] cpio - segmentation violation

peter@essex.ac.uk (Allott P) (06/14/89)

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);
}
============================================================================

gwyn@smoke.BRL.MIL (Doug Gwyn) (06/17/89)

In article <1120@servax0.essex.ac.uk> peter@essex.ac.uk	 (Allott P) writes:
>The problem is that some users have files on their areas with a uid of -2.

That NFS-induced modification to the concept of UID has caused numerous
problems.  AT&T UIDs are unsigned (i.e. nonnegative) integers, and AT&T
UNIX software relies on this.  (So did some BSD software.)  The whole
issue of NFS ID mapping has been a real mess.

prp@sei.cmu.edu (Patrick Place) (06/19/89)

In article <10406@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
> In article <1120@servax0.essex.ac.uk> peter@essex.ac.uk	 (Allott P) writes:
> >The problem is that some users have files on their areas with a uid of -2.
> 
> That NFS-induced modification to the concept of UID has caused numerous
> problems.  AT&T UIDs are unsigned (i.e. nonnegative) integers, and AT&T
> UNIX software relies on this.  (So did some BSD software.)  The whole
> issue of NFS ID mapping has been a real mess.


It is not so much a matter of having negative uids (which I admit is
unusual) as that on Suns for example,
	printf("%.6ho", -2)
will print a 10 character wide representation of -2, rather than
the requested 6 character representation.  I had exactly this problem
and fixed it by casting the offending value to a halfword, having
masked off all but the last 16 bits.  It seemed to work and allowed
me once again to read (and write) cpio archives.  I will grant that
the fix is not pretty, but I could not come up with any other way to
make printf print out a 6 character wide value.  To be fair, if I
recall my reading of the Sun manual page for printf, it doesn't
guarantee that it will limit the output to 6 characters, merely that
it will use 6 characters (ie pad if necessary).

Pat Place

guy@auspex.auspex.com (Guy Harris) (06/28/89)

>That NFS-induced modification to the concept of UID has caused numerous
>problems.

There's nothing about NFS that requires that "nobody" be a negative UID;
I suspect future SunOS releases, and the NFS source releases derived
from them, will follow 4.xBSD and S5 and have unsigned UIDs with
"nobody" becoming 65534 or something like that.

>The whole issue of NFS ID mapping has been a real mess.

Separate issue(s): 1) RFS-style mapping has, I think, been implemented
by Cray, and 2) RFS also has, I think, the same notion of a "nobody" UID.