First off, you need to be aware that there is not necessarily a 1:1
mapping between inode number and absolute path. There can be many
absolute paths, or even *no* absolute paths to an inode.
Furthermore, inodes are not guaranteed to be unique on the entire
system. They *are* unique within a given filesystem however.
There isn't really a structure that will let you directly find what
you're looking for, at least that I know of. That said, it *is*
possible to find a given inode using a search using the <dirent.h> and
stat(2) interfaces. There's even a utility that will do this for you
from the command line -- find(1).
To use it, start at the root of the filesystem you want to search, and
use -inum like this:
# the following two values are hypothetical
filesys=/
inum=733
find $filesys -xdev -inum $inum
Btw, you probably don't want to be looking at the kernel interfaces in
uts/ unless you have a specific need for kernel level code.
- Garrett
On 05/ 3/10 05:53 PM, Edward Ned Harvey wrote:
I have a specific task at hand, but I'm feeling a little bit
overwhelmed, so I'm looking for any guidance possible, to keep me on
track, or otherwise, anything that can help me keep moving toward my
goal... Hell, if you want to write 15 lines of code for me, I would
sure be happy. ;-) But I'm not expecting that.
I am not usually an opensolaris contributor. I don't need to become
an expert (I hope.) I do have a degree in CS, so I'm plenty familiar
with C/C++, but at work, I'm mostly an IT guy and less a software
developer. So I should be considered an entry level (but basically
qualified) programmer.
Specifically, I want to reverse lookup, inode number --> absolute
path. I understand this can only be done by root, and presents at
least some security risk, and cannot be done for files (only
directories) and many other limitations. But I want to do it anyway.
I am aware of
http://opensolaris.org/sc/src/crypto/quantis/usr/src/uts/common/fs/lookup.c
/*
* Given a directory, return the full, resolved path. This looks up "..",
* searches for the given vnode in the parent, appends the component,
etc. It
* is used to implement vnodetopath() and getcwd() when the cached
path fails
* (or vfs_vnode_path is not set).
*/
static int
dirtopath(vnode_t *vrootp, vnode_t *vp, char *buf, size_t buflen,
cred_t *cr)
{
The problem I'm facing is: When I look up vnode_t, it appears to be a
huge struct, with all the variables etc having names and such, which I
don't understand, and I don't know how to properly create this
object. I don't see any documentation explaining what vrootp is, or
vp, or how to construct those items correctly ... And I haven't even
come to the point of even **attempting** to figure out cred_t yet.
And a really basic obvious question ... Should I "#include <lookup.c>"
or something similar? It don't seem right.
Do I need to extract some source tarball in order for these to become
available? I assume it's not available by default.
So today, I started reading the Opensolaris ON Developer's Reference
Guide ... and quickly started thinking it's probably dramatic overkill.
I would greatly benefit by simplifying the problem. And so I'm
throwing a blind dart, hoping for the almighty gods of the mailing
list to offer some guidance...
Thanks in advance...
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
