From owner-freebsd-hackers Sat Nov 20 19:37:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id F1C4C15195 for ; Sat, 20 Nov 1999 19:37:43 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id WAA03228; Sat, 20 Nov 1999 22:36:48 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Sat, 20 Nov 1999 22:36:48 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Wes Peters Cc: "Daniel C. Sobral" , John Polstra , Garance A Drosihn , hackers@FreeBSD.ORG Subject: Re: Portable way to compare struct stat's? In-Reply-To: <38376544.96B017E9@softweyr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 20 Nov 1999, Wes Peters wrote: > "Daniel C. Sobral" wrote: > > > > Wes Peters wrote: > > > > > > It's not broken in this case. 2^16 (st_dev) is certainly enough to uniquely > > > indentify all mounted filesystems, and 2^32 is (by definition) enough to > > > uniquely indentify each of the files on a filesystem. Discussions (with > > > strong, valid reasons) about expanding the size of ino_t should be carried > > > out on -arch. > > > > Just to expand a little bit more, some distributed filesystems *do > > not* have a unique identifier like the inode. > > So then the FreeBSD client software should create one? Do they just assign > a random number as the st_ino when stat'ing the file? The problem isn't creating a unique number for a file, it's maintaining the consistency of that unique number over time -- the POSIX quote in question wanted the number to continue to identify the file over more than the single stat reference. Otherwise, we could assign random numbers, incrementing numbers, zero, etc, each reference. Using a unique 32-bit number to identify a file uniquely doesn't work for a large class of file systems, and therefore would appear to be an fs-specific piece of functionality -- something that should not be exposed in an fs-general way--i.e., in the VFS, which is supposed to describe features common across file systems. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message