>I know it's very strange to do that since we have the file name when
>we call:
int open(const char *pathname, int oflag,...);
And we can store the file name for later usage.
The POSIX API is more on-topic in comp.unix.programmer. Standard
C doesn't define an open() call, and not all systems are POSIX.
>But I just wonder if we can get a file name from the file descriptor
(on Windows/Linux), then the solution may looks simpler (if it's not
so hard to get the file name, :) ).
First of all, under POSIX, there isn't *THE* name: a given open
file may have zero or more names. It might have zero if the name
has been remove()d or rename()d over, but it's still open. It might
have several names due to hard links. That's not even counting
symlinks and variant pathnames involving /../ in the path which
might have been used in the open() call.
Under POSIX, it is possible, *if* you have the permissions necessary,
to find some name(s), if any, assuming they are not changing out
from under you. However, nobody said it would be efficient.
On a certain large newsserver, treewalking one filesystem looking
for a particular inode could take *hours*. If it was also handling
news readers at the time, it might take a whole day.
The following procedure works on POSIX, but I'm not sure about
Windows, especially with a FAT or NTFS filesystem:
fstat() the open file. Note the st_dev and st_ino fields returned.
Treewalk the entire file system. Find names with the same st_dev
and st_ino fields. These are the names for the file, or at least
were when they were found. Note that there are some shortcuts (but
system-dependent, even for POSIX) you can use with mount points and
the mount table to only treewalk the relevant filesystem, rather
than the whole system.