how to get the filename of a FILE pointer

[hilz]

Hi all:
I have a FILE pointer that points to a file on disk (not any other io
stream). is there a way to get the filename of that FILE?
i thought it would be the _tmpfname part of the struct, but it doesn't look
like it

thanks
hilz

[Ben Pfaff]

"hilz" <no****@nowhere.com> writes:

I have a FILE pointer that points to a file on disk (not any other io
stream). is there a way to get the filename of that FILE?

Not portably.
--
"When I have to rely on inadequacy, I prefer it to be my own."
--Richard Heathfield

[Gordon Burditt]

>I have a FILE pointer that points to a file on disk (not any other io

stream). is there a way to get the filename of that FILE?
i thought it would be the _tmpfname part of the struct, but it doesn't look
like it

This is highly system-dependent and likely very expensive. On some
systems, you can do a file-tree walk, stat() each file looking for
one with a matching device and inode numbers. BUT: there's no
guarantee that a file still has a name. (unlinking an open file
is not guaranteed to destroy the file). There's no guarantee that
a file has only one name (even if you don't follow symlinks). And
even if it does have a name, there's no guarantee that you have
permission to use it or even determine it. And, of course, there's
no guarantee that your system even HAS stat(), symlinks, device
numbers, inode numbers, opendir(), readdir(), or unlink().

File-tree walks on some systems (particularly large news servers
with terabytes of storage) can take days. This is not something
you want to do lightly.

If you fopen()ed the file yourself, SAVE THE NAME if you're going
to need it. If the FILE in question is stdin, stdout, or stderr,
maybe the program interface should be changed so you supply a
filename instead.

Gordon L. Burditt

[E. Robert Tisdale]

hilz wrote:

I have a FILE pointer that points to a file on disk
(not any other I/O stream).
is there a way to get the filename of that *FILE?
No.
I thought it would be the _tmpfname part of the struct,
but it doesn't look like it

[James McIninch]

You cannot get the filename. What if the file has two names?

hilz wrote:

Hi all:
I have a FILE pointer that points to a file on disk (not any other io
stream). is there a way to get the filename of that FILE?
i thought it would be the _tmpfname part of the struct, but it doesn't
look like it

thanks
hilz

--
remove .nospam from e-mail address to reply

[hilz]

"Gordon Burditt" <go****@hammy.burditt.org> wrote in message
news:ck********@library2.airnews.net...

I have a FILE pointer that points to a file on disk (not any other io
stream). is there a way to get the filename of that FILE?
i thought it would be the _tmpfname part of the struct, but it doesn't looklike it

This is highly system-dependent and likely very expensive. On some
systems, you can do a file-tree walk, stat() each file looking for
one with a matching device and inode numbers. BUT: there's no
guarantee that a file still has a name. (unlinking an open file
is not guaranteed to destroy the file). There's no guarantee that
a file has only one name (even if you don't follow symlinks). And
even if it does have a name, there's no guarantee that you have
permission to use it or even determine it. And, of course, there's
no guarantee that your system even HAS stat(), symlinks, device
numbers, inode numbers, opendir(), readdir(), or unlink().

File-tree walks on some systems (particularly large news servers
with terabytes of storage) can take days. This is not something
you want to do lightly.

If you fopen()ed the file yourself, SAVE THE NAME if you're going
to need it. If the FILE in question is stdin, stdout, or stderr,
maybe the program interface should be changed so you supply a
filename instead.

Gordon L. Burditt

The problem is that the FILE pointer is supplied to me by a third party
function that i have no control over, and there is no way i can get the name
from anywhere else. So unfortunately, i cannot "SAVE THE NAME".

In addition, I am working exclusively with Window$ where there is only one
file with that name and path.
does that make it possible now?

thanks
hilz

[Ben Pfaff]

"hilz" <no****@nowhere.com> writes:

In addition, I am working exclusively with Window$ where there is only one
file with that name and path.
does that make it possible now?

Asking Windows questions in Windows newsgroups improves your
chances at a useful response.
--
Ben Pfaff
email: bl*@cs.stanford.edu
web: http://benpfaff.org

[hilz]

> Asking Windows questions in Windows newsgroups improves your

chances at a useful response.

i thought this was more of a C question than a Windows question.
If not, i appologize.

[CBFalconer]

hilz wrote:

I have a FILE pointer that points to a file on disk (not any other
io stream). is there a way to get the filename of that FILE?
i thought it would be the _tmpfname part of the struct, but it
doesn't look like it

You had the filename when you fopened the file. Use that.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Gordon Burditt]

>> >I have a FILE pointer that points to a file on disk (not any other io

>stream). is there a way to get the filename of that FILE?
>i thought it would be the _tmpfname part of the struct, but it doesn'tlook >like it
This is highly system-dependent and likely very expensive. On some
systems, you can do a file-tree walk, stat() each file looking for
one with a matching device and inode numbers. BUT: there's no
guarantee that a file still has a name. (unlinking an open file
is not guaranteed to destroy the file). There's no guarantee that
a file has only one name (even if you don't follow symlinks). And
even if it does have a name, there's no guarantee that you have
permission to use it or even determine it. And, of course, there's
no guarantee that your system even HAS stat(), symlinks, device
numbers, inode numbers, opendir(), readdir(), or unlink().

File-tree walks on some systems (particularly large news servers
with terabytes of storage) can take days. This is not something
you want to do lightly.

If you fopen()ed the file yourself, SAVE THE NAME if you're going
to need it. If the FILE in question is stdin, stdout, or stderr,
maybe the program interface should be changed so you supply a
filename instead.

Gordon L. Burditt

The problem is that the FILE pointer is supplied to me by a third party
function that i have no control over, and there is no way i can get the name
from anywhere else. So unfortunately, i cannot "SAVE THE NAME".

This depends on how badly you need it. Sometimes you need it so
bad you can afford to not only scrap or replace the existing system,
but also its OS, the entire office staff, the building, and the
whole site (meaning land, not hostname) and perhaps even a whole
country. Or, you could BUY the third party. Microsoft does that
a lot. And it might even be faster.
In addition, I am working exclusively with Window$ where there is only one
file with that name and path.
Yes, but is there only one name and path for that file? I thought
Windows had long and short names for just about every file and
directory, therefore making many names for the same file very common.
does that make it possible now?

Possible, maybe, fast, unlikely, portably, no chance. If you
don't insist on a unique filename, just at least one that works
when running with Administrator privilege, probably.

Does your compiler have stat() for Windows? My guess is that it
probably does. Does your compiler have something that can do the
equivalent of stat() on an open stream? (e.g. on UNIX, fstat() on
fileno(stream)). A bit less obvious, but probably available. Does
stat() return device and inode numbers that *UNIQUELY IDENTIFY A
FILE*? (as distinguished from dummy numbers). This I am not sure
about. I don't think Windows filesystems HAVE inode numbers and
I'm not sure they have any kind of unique file number.

You're trying to match these numbers from fstat() on the open stream
against stat() on files in the filesystem to find a match. If they
are dummy, forget it, many unrelated files will match.

How long does it take for you to get Windows to scan your whole
hard disk to look for files of a particular type (using, for example,
the Windows "Find a File" GUI)? This is probably how long a full
tree-walk will take. Is this acceptable speed? On a bare-bones
Windows XP system (just about the only application installed or
ever used is Windows Update) with about 8GB of disk space, this
took 5 minutes (certainly unacceptable for a Web application. Maybe
no problem for a batch job). How much this takes on your system
will depend on whether your disk is bigger than your processor or
vice versa.

Gordon L. Burditt

[Dik T. Winter]

In article <3N09d.12041$na.8192@trnddc04> "hilz" <no****@nowhere.com> writes:

Asking Windows questions in Windows newsgroups improves your
chances at a useful response.

i thought this was more of a C question than a Windows question.
If not, i appologize.

You have gotten your C answer. It can not be done in standard C.
Whether it is possible on your platform is a different question,
and that is indeed a Windows question, so platform dependent.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Kenneth Brody]

hilz wrote:
[...]

The problem is that the FILE pointer is supplied to me by a third party
function that i have no control over, and there is no way i can get the name
from anywhere else. So unfortunately, i cannot "SAVE THE NAME".

In addition, I am working exclusively with Window$ where there is only one
file with that name and path.
does that make it possible now?

I know there is some way under Windows to go from handle to filename, as
I have utilities that display all open files in a process, including the
handle and filename, among other information. However, this is highly
Windows-specific.

How to do that, I couldn't say, but one of the Windows newsgroups would
be a good place to start. Perhaps "comp.os.ms-windows.programmer.win32"?

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+