From owner-freebsd-hackers Fri Feb 19 17:20:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 8D81E1192A for ; Fri, 19 Feb 1999 17:19:52 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id SAA27484; Fri, 19 Feb 1999 18:19:52 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpd027447; Fri Feb 19 18:19:49 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id SAA17512; Fri, 19 Feb 1999 18:19:44 -0700 (MST) From: Terry Lambert Message-Id: <199902200119.SAA17512@usr02.primenet.com> Subject: Re: UIDs greater than 65535? To: jdp@polstra.com (John Polstra) Date: Sat, 20 Feb 1999 01:19:44 +0000 (GMT) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: from "John Polstra" at Feb 19, 99 04:36:50 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> Can anybody think of a reason why UIDs > 65535 wouldn't work under > >> FreeBSD? They seem to work, and I can't find any reason why they > >> shouldn't. Even the NFS protocol (though not necessarily all NFS > >> servers) seems to be able to accomodate 4-byte UIDs. > > > > 65536 in an unsigned short is -1 is "nobody". > > Actually, nobody is 65534 on FreeBSD systems. But anyway, I've only > found a couple of places where UIDs are stored in unsigned shorts: I meant 65535, but yeah, -2 is right. I can't remember back to Ultrix, but I know -1 was *something*; ah, got it. It's who root becomes if you don't allow root access via NFS. > * In the API to the System V message functions, in . > * In Linux programs run under emulation. > > There are also some limits in archive files, because UIDs are encoded > as (*gag*) 5-digit decimal numbers. > > These problems are all avoidable in the application I have in mind. See the quota code. The thing uses a sparse file, and spazzes out > 65535. Not that it has spare space for the time_t going to 64 bits anyway. 8-(. I have a quota stacking layer that resolves both the Year 2038 issues and the uid_t/gid_t issues, includes version stamping the file, and has a format converter (quotacheck -c 1), but it won't run in an unhacked FreeBSD kernel because of my local VFS changes to support stacking layers actually working, and cleaner vnode based kernel file I/O. I think a stacking layer is the way to go; I can put quotas on my ext2fs and UMSDOS (stack over VFAT, using Udo Walter's attribute file: -linux--.--- [bletch] or mine: -umsdos-.--- [yea, symmetric, not OS tagged]) FS's. Woo hoo. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message