marco@andromeda.UUCP (the wharf rat) (10/18/86)
First, anyone remember my problem with "sh :pwd: cannot open .." ?
I'm not sure my followup ever got out; so thanks to all who responded, and
the problem turned out to be a broken directory where a local utility lived.
Now, my next question: Is there any way to "get" an i-node into a C
program, the way getpwent gets passwd entries ? Do I really have to
open the device file and look for the i-list ?
W.ratgwyn@brl-smoke.ARPA (Doug Gwyn ) (10/19/86)
In article <47@andromeda.UUCP> marco@andromeda.UUCP (the wharf rat) writes:
- Is there any way to "get" an i-node into a C program,
- the way getpwent gets passwd entries?
Yes, it's called stat().jrw@hropus.UUCP (Jim Webb) (10/19/86)
> Is there any way to "get" an i-node into a C > program, the way getpwent gets passwd entries ? Do I really have to > open the device file and look for the i-list ? The stat(2) call yields a lot of info in the inode, but if you are looking for block info, reading the inode is the only means of getting it. There is not a getinode() function, but it would be a very simple function to write. Under System V, the physical disk slice looks like this: block 0 block 1 block 2 .... +------------+------------+---------------------------+--------------- | BOOT BLK | SUPER BLK | INODES.... | DATA BLOCKS +------------+------------+---------------------------+--------------- So, to grab the inode, all one has to do is to lseek past the boot and super- blocks, and then, using the inode number, lseek into the ilist and read out the inode: #include <sys/types.h> #include <sys/ino.h> #include <fcntl.h> int fd; ino_t inum; struct dinode ibuf; fd=open("/dev/rdsk/0s0",O_RDONLY); lseek(fd,1024+inum*sizeof(struct dinode),0); read(fd,ibuf,sizeof(struct dinode)); Then you can look at any of the inode info via ibuf. -- Jim Webb "Out of phase--get help" ...!ihnp4!hropus!jrw "Use the Force, Read the Source"
larry@kitty.UUCP (Larry Lippman) (10/23/86)
In article <47@andromeda.UUCP>, marco@andromeda.UUCP (the wharf rat) writes: > Now, my next question: Is there any way to "get" an i-node into a C > program, the way getpwent gets passwd entries ? Do I really have to > open the device file and look for the i-list ? 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. The above applies to System V; but I can't speak for Beserkeley. ==> Larry Lippman @ Recognition Research Corp., Clarence, New York ==> UUCP: {allegra|decvax|rocksanne|rocksvax|watmath}!sunybcs!kitty!larry ==> VOICE: 716/688-1231 {hplabs|ihnp4|seismo|utzoo}!/ ==> FAX: 716/741-9635 {G1,G2,G3} "Have you hugged your cat today?"
guy@sun.UUCP (10/23/86)
> 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)
jjw@celerity.UUCP (Jim ) (10/27/86)
>> Is there any way to "get" an i-node into a C >> program, the way getpwent gets passwd entries ? Do I really have to >> open the device file and look for the i-list ? > >The stat(2) call yields a lot of info in the inode, but if you are >looking for block info, reading the inode is the only means of getting >it. Note that doing this is inherently non-portable and, if it is used in a program which will be used for more than a short time, it may break several years down the line if the inode is changed due to the addition of some new feature.