Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!husc6!mit-eddie!genrad!decvax!decwrl!sun!guy
From: guy@sun.UUCP
Newsgroups: net.unix
Subject: Re: inodes
Message-ID: <8425@sun.uucp>
Date: Thu, 23-Oct-86 05:14:33 EDT
Article-I.D.: sun.8425
Posted: Thu Oct 23 05:14:33 1986
Date-Received: Fri, 24-Oct-86 00:22:36 EDT
References: <47@andromeda.UUCP> <1370@kitty.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 36

> 	Use stat(2) if you have a pathname for a file, or fstat(2) if you
> have a file descriptor resulting from another system call which has already
> opened the file.
> 	Both stat(2) and fstat(2) return a pointer to a stucture (found in
> /usr/include/sys/stat.h), in which the variable st_ino is the inode number.

He doesn't seem to want the inode *number*, he seems to want the inode
itself.  All "stat" or "fstat" does is give you some selected fields from
the inode.

The appropriate way to answer his question might be to ask another question
(as seems to be the case with most questions about UNIX I see).  That
question is "What do you want to do with this inode once you've got it?"  It
may be that "stat" or "fstat" will be sufficient, if he only wants some
fields from the inode for a file for which he has a pathname or file
descriptor.  However, given his mention of "getpwent" as a routine providing
for "/etc/passwd" the function he wants for the i-list, I suspect he wants
to write a program to scan the i-list for inodes for which some predicate
is true, or a program to dump the i-list.  In this case, the calls to "stat"
that some people have suggested won't do the job.

> 	The above applies to System V; but I can't speak for Beserkeley.

The 4.2BSD "stat" system call is perfectly described by the System V manual
page for "stat" (before someone pipes up that "'st_atime' and 'st_mtime'
aren't contiguous, so some programs break," I will point out that the S5
manual page *goes out of its way* to make no claims whatsoever about the
layout of the "stat" structure, and that the S5 "lint" library entry for
"utime" will catch any program that misuses those fields by passing a
pointer to the "st_atime" field to "utime").  The only thing to note is that
"stat" follows symbolic links, so it won't give you the data from the
symbolic link's inode, but the inode that it points to.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com (or guy@sun.arpa)