inode -> file name

sunnycoder,
Doing a full scan of the FS won't do... No other choices?

Stefan

Nope ... None as far as I know

The issue first came up in http:Q_20658408.html and then perhaps you picked it up from http:Q_20976945.html

btw, if you did a stat then you have fd ... If you have fd then you can get the information directly on linux (and only linux)

use getpid to get current process pid and then

ls -l /proc/pid/fd

this will give all fd's and their associated files ... which can be parsed to find the file associated with your fd

But you need a filename to stat.

if you randomly choose an inode.
Sunny's idea is good but time consuming.

CAn we get the inode num of the parent directory from the file's inode. If it is then
One readdir will do.

regards manish

Manish, that is almost always true ... but there are occasions when all you have is an fd and all you can do is an fstat (I did write stat in my previous post which was a mistake)

The two links I posted above had that exceptional situation.

I said,
>That said, isn't an inode an index into a file system table? I know us
>"mortal" users are not supposed to know or meddle with such things,
>but given enough info, it seems there has to be an efficient way for
>looking up the filename.

But, I now think this is a false lead. The actual inode structure has no
reference to any names at all. It really only contains:
 - size information
 - physical addresses of the blocks the file uses.
 - modification times.

The only place that a name comes into play is within directory structures.
A directory file isn't much more than just a list of:
 file name --> i-number for that file.

Hence, I would expect sunny's brute force search to be the only practical way
to find this mapping within a file system.

You are quite right Tim ... I never thought about mounted filesystem ... That was quite a trap ;o)

>but given enough info, it seems there has to be an efficient way for
>looking up the filename.
The question troubled me for sometime ... For the efficient way, we need inode or one of its descendends to point to filename ... All fields of inode are not standardized and I could not find even a non-standard implementation which does that (To be honest I did not look too hard either ;o) )

LOL ... I am glad that I did not look too hard ;o)

I guess the reason for this is

inodes are used by kernel for internal references and functioning ... This has nothing to do with what file the inode is associated with and inodes were never meant for user's consumption ... Hence filename field was never put there

Also one would reasonable expect that you do not guess inode number for your file from random number generator .. rather you obtain it using one of the APIs provided ... To call that API, you would have known the file name at some point of time !! If you will need it later, save it ... If you need it and haven't saved it, it is probably poor design

just my thoughts

Yes, I do have a proc FS here on Solaris, but all I find in the fd subdir is just something like

ls -l /proc/$$/fd
total 0
c---------   1 root     sys       13,  2 May  5 13:11 0
c---------   1 root     sys       13,  2 May  5 13:11 1
c---------   1 csmdev4  tty       24,134 May  5 13:11 15
c---------   1 csmdev4  tty       24,134 May  5 13:11 16
c---------   1 csmdev4  tty       24,134 May  5 13:11 17
c---------   1 csmdev4  tty       24,134 May  5 13:11 18
c---------   1 csmdev4  tty       24,134 May  5 13:11 19
c---------   1 root     sys       13,  2 May  5 13:11 2

...which is not of much help :-/

>If you have fd then you can get the information directly on linux (and only linux)
try it on a linux box ...
here is a sample output from my linux box

lrwx------    1 user  user        64 May  5 16:49 0 -> /dev/pts/1
lrwx------    1 user  user        64 May  5 16:49 1 -> /dev/pts/1
lrwx------    1 user  user        64 May  5 16:49 2 -> /dev/pts/1
lrwx------    1 user  user        64 May  5 16:49 255 -> /dev/pts/1

sunnycoder,
I see. I'll have a look at the lsof sources, that might give me an answer for Solaris, too.

But lsof is suid root :-/

Stefan

c---------   1 root     sys       13,  2 May  5 13:11 0
c---------   1 root     sys       13,  2 May  5 13:11 1
c---------   1 csmdev4  tty       24,134 May  5 13:11 15
c---------   1 csmdev4  tty       24,134 May  5 13:11 16
c---------   1 csmdev4  tty       24,134 May  5 13:11 17
c---------   1 csmdev4  tty       24,134 May  5 13:11 18
c---------   1 csmdev4  tty       24,134 May  5 13:11 19
c---------   1 root     sys       13,  2 May  5 13:11 2

Also read the proc man page for solaris ... The last column could be fd

sunnycoder,
> The last column could be fd
Yes, that's the fd. But a lot less helpful than on Linux :-/

Stefan

But atleast there is way ... 10 minutes ago there was none ;o)

sunnycoder,
Assuming I start with an fd, it's not too helpful...

Stefan

>inodes are used by kernel for internal references and functioning
realized this same thing right after I posted my first comment, hence, the quick retreat. : )

On Linux, it appears that the fd subdirectory stores its "files"
(whose name is the file descritor integer) as symbolic links (ls dereferences these for us).

c---------   1 root     sys       13,  2 May  5 06:58 0
Solaris is a bit more cantankerous and stores them only as character devices.

lsof does read out of /dev/kmem and that is the need for the suid bit. : (
No doubt, that will lead to a solution. Good luck on this.
- Tim

To reiterate/summerize:

o  If you have an open file-descriptor, then you should be able to use /proc if your OS flavor support the necessary functionality (i.e., probably not if you're not on Linux). You can not walk up the file tree with the moral equivalent of 'cd ..' because open file descriptors only point you at the data-blocks for the file in question, not at the name-space/directory information - see below.

o  Otherwise, if you have a kernel device nubmer and an inode number (the thing you get from stat/fstat), you can do an exhaustive search (using stat to make sure the device number matches).

o  If you just have an inode number, you can do an exaustive search and get all the candidate files with the same inode number but with different device numbers.

Why is this so difficult, you ask? Because the inodes point only at the data-space of the filesystem, not at the name-space. This is because the name-space is not a onoe-to-one mapping to the data-space.

For example, every directory has several different places in the name-space pointing at the same data-space - the name of the directory in the parent directory, '.' in the directory itself, and '..' in any child directories.

And regular files can also have multiple names for the same files. The diffent names are referred to as 'hard links' to each other in this case. For example, here's the output of 'ls -li /usr/bin/* | grep 259254' on a Solaris 8 box:
    259254 -r-xr-xr-x   5 root     bin       226656 Oct 11  2003 /usr/bin/edit*
    259254 -r-xr-xr-x   5 root     bin       226656 Oct 11  2003 /usr/bin/ex*
    259254 -r-xr-xr-x   5 root     bin       226656 Oct 11  2003 /usr/bin/vedit*
    259254 -r-xr-xr-x   5 root     bin       226656 Oct 11  2003 /usr/bin/vi*
    259254 -r-xr-xr-x   5 root     bin       226656 Oct 11  2003 /usr/bin/view*

As you can see, these are actually all the same underlying file / inode, but with different names. And they could just as easily have been in completely differnet parts of the filesystem, say by doing
    mkdir -p /usr/foo/bar/1/2/3
    ln /usr/bin/vi /usr/foo/bar/1/2/3/vi

0.  inode numbers are only relevant for a particular filesystem.  To identify a file, you really need the combination of inode and a filesystem identifier of some sort (like a mountpoint or device name).
1.  inodes do not have a filename associated with them.
2.  filenames are contained within directory entries, which refer to the inode number.
3.  Through hard-linking, more than one filename can refer to the same inode and file.
4.  It is possible for one program to open a file just before another deletes it.  In this situation, the file and inode continue to exist while the first program maintains the file descriptor to it, but at this time there is no directory entry in the filesystem that refers to the inode.  When the descriptor is closed, the OS deletes the file and frees up the inode.
5.  Therefore, the best you can hope for is to traverse the filesystem's entire directory structure (ala the find command above) and get a list of all filenames that refer to that particular inode.  It is possible that you will not find any directory entries that refer to the inode.

Note that there is no unix API command called "delete()", only one called "unlink()".  Its action is to remove a hard-link to an inode, without caring whether or not there are other links to that inode.

If you use the find command above, be sure to use the -mount option so find doesn't go wandering off onto another filesystem.