Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!longway!std-unix
From: karish@forel.stanford.edu (Chuck Karish)
Newsgroups: comp.std.unix
Subject: Re: POSIX, NFS, CPIO/TAR
Keywords: POSIX, NFS, CPIO/TAR
Message-ID: <478@longway.TIC.COM>
Date: 16 Dec 89 04:43:40 GMT
References: <2587D93A.19FD@marob.masa.com> <7674@portia.Stanford.EDU> <474@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: karish@forel.stanford.edu (Chuck Karish)
Organization: Mindcraft, Inc.
Lines: 28
Approved: jsq@longway.tic.com (Moderator, John S. Quarterman)

From: karish@forel.stanford.edu (Chuck Karish)

In article <474@longway.TIC.COM> Doug Gwyn <uunet!brl.mil!gwyn> wrote:
>From: Doug Gwyn <uunet!smoke.brl.mil!gwyn>
>In article <7674@portia.Stanford.EDU> karish@forel.stanford.edu
(Chuck Karish) writes:
>>  [something stupid]

>IEEE Std 1003.1 defines "group ID" and "user ID" to be NON-NEGATIVE
>integers in Section 2.3.  This is in conformance with existing practice
>that Sun gratuitously ignored in their NFS implementation.

Hmmm.  This could, indeed, cause problems.

The original posting pointed out that that some vendors hedge on this
issue by making the types unsigned short, so the negative values are
cast to large (near USHRT_MAX) positive numbers.  Of course, this will
fail if a tar or cpio archive is unpacked on a system where uid_t and
gid_t are signed types longer than 16 bits, so 65534 != -2.

Who's going to change?  For that matter, will other 1003.1 semantics be
compromised to accomodate NFS as a transparent file access standard?
Stay tuned...

	Chuck Karish		karish@mindcraft.com
	(415) 323-9000		karish@forel.stanford.edu

Volume-Number: Volume 17, Number 105