Date: Sat, 20 Nov 1999 22:36:48 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Wes Peters <wes@softweyr.com> Cc: "Daniel C. Sobral" <dcs@newsguy.com>, John Polstra <jdp@polstra.com>, Garance A Drosihn <drosih@rpi.edu>, hackers@FreeBSD.ORG Subject: Re: Portable way to compare struct stat's? Message-ID: <Pine.BSF.3.96.991120223205.3198A-100000@fledge.watson.org> In-Reply-To: <38376544.96B017E9@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.991120223205.3198A-100000>