Filename from Handle?

[Paul Squires]

I am using the Windows API to open files. I know the open file
handle. Given this handle how do I find out what file name is
associated with it? Even better would be to know the full path
and file name associated with the handle.



------------------
Paul Squires
www.PlanetSquires.com
mailto:[email protected]
[email protected]
</A>

[Michael Mattias]

Am I missing something?

I am using the Windows API to open files. I know the open file
handle

If you open the file with the Windows API, don't you have the filename?

If not, how did you open it?

MCM

[Paul Squires]

Michael, you're right of course. I do know the file name when the
file is opened, but I want to know the name elsewhere in my program
and I was hoping to get away without having to save it in a
global variable (I have many open handles so there would be many
globals). I only need to reference the filename once so saving
it just for that purpose seems a little wasteful to me.

PB has a built in function called FILENAME that returns the
filename of a file opened using PB's internal file commands. I
assumed that the Windows API would have something similar for
its open file handles.

Also, how about the situation where you open the file but another
application changes it (e.g. Windows Explorer). My internal global
filename would be different than the new name. See what I mean???

Thanks,



------------------
Paul Squires
www.PlanetSquires.com
mailto:[email protected]
[email protected]
</A>

[Michael Mattias]

Then add a FUNCTION to your application, a FUNCTION you can call from anywhere:

FUNCTION FilesAndOpenHandles (Action AS LONG, szFileName AS ASCIIZ * %MAX_PATH, FileHandle AS LONG) AS LONG
...

Where
Action = %ADD_FILE Pass szFileName and handle
Action = %GET_FILE_FROM_HANDLE Pass Handle, get back filename
Action = %GET_HANDLE_FROM_FILE pass filename, get back handle
Action = %DELETE_FILE pass handle

Just keep a STATIC array or a linked list within the FUNCTION.

Call each time you open or close a file.

Write once, use many.

MCM

[Paul Squires]

I see what you mean.

Hmmmmm.... but would that save me any memory? I still have to
create a static array to hold the filenames for the life of the
program. Currently, I have a TYPE allocated for each open handle
that holds various information about the open file (actually, the
file is a database). I could easily add a member to the structure
to hold the filename and full path but I was hoping to avoid
that.

Oh well, I guess I am only adding a little bit of overhead so I
might as well do it.

I just thought that if there was a simple Windows API call that
could get the name for me then I could forgo having to manually
save the values myself.

Thanks,


------------------
Paul Squires
www.PlanetSquires.com
mailto:[email protected]
[email protected]
</A>

[Michael Mattias]

Um, why are you worrying about memory?

So let's say you have 100 files open. (This is a huge and unrealistic number)

You'll need 100 * %MAX_PATH bytes of storage, or 26,000 bytes.

Your Windows program has available to it some 2,000,000,000 bytes.

In a series of articles I wrote for Basically Speaking, I dealt with this resource utilization issue. I wrote in one article the biggest change I underwent looking at the difference between DOS and Windows was the huge amount of random-access memory available, and the hardest thing about conversion was getting over the 'scrimp and save' mindset necessary to develop DOS applications working in a 640K universe.

All deference to commercial products aside, you have to start thinking outside the "DOS box."

MCM

[Eric Pearson]

> So let's say you have 100 files open.
> (This is a huge and unrealistic number)

Not necessarily. I have a Report Generator program that routinely opens up to 366 files, all at the same time. And it has an option that allows up to 3660 files, although it is rarely used.

Also, that same program is extremely memory-intensive. It uses every scrap of memory that it can, so I tried to minimize the amount of memory that is "wasted".

That being said, I did not find a good way to avoid storing the file names as strings.

I considered using a disk file to store them, but then I remembered that Windows caches disk files when they are read, so the "memory savings" would be an illusion.

Paul, do you have control over the file names? If so, you could used names like 00000001.DAT and store numbers in an array, which could be used to "construct" the file names when they were needed.

Overall, I agree with Michael. I don't know how much memory is required for each open file -- probably at least 4k for the buffer, and then some -- so adding 270 bytes to store the file name is a pretty small additional price to pay.

-- Eric


------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>

[Paul Squires]

Points well taken.

I have included the filename (and path) in my TYPE array so I
will get the functionality I need. I do fall into a DOS mentality
every now and again - hard habit to break.

The question here is not so much memory utilization, but rather
is there a Windows API function that can return the file name from
a handle. I haven't found one. I thought there may be one because
of PB's built in FILENAME function. I thought maybe that was
modelled after an API function.

Thanks for the replies. No further need to continue this thread.

Thanks,



------------------
Paul Squires
www.PlanetSquires.com
mailto:[email protected]
[email protected]
</A>