get filename using filehandle

Started by fhammer, January 25, 2019, 08:47:05 PM

Previous topic - Next topic

fhammer

Is there a way to retrieve the filename, using only the filehandle of an open file?

Thank you.

td

Probably an easier way but here is one approach:

Code (winbatch) Select
;; Open a test file.
hDummy = FileOpen('c:\temp\dummy.txt', 'Read')

;; Convert the handle to a win32 file handle.
hFile = Intcontrol(94, hDummy, 0, 0, 0)

;; Get the test file's full cononical name.
nBuffSize = 260 ; MAX_PATH
hBuffer = BinaryAlloc(nBuffSize)
nChars = DllCall('kernel32.dll',long:'GetFinalPathNameByHandleA', long_ptr:hFile, lpbinary:hBuffer, long:nbuffSize, long:0)
BinaryEODSet(hBuffer, nChars)
strFullName = BinaryPeekStr(hBuffer, 0, nChars)

BinaryFree(hBuffer)
FileClose(hDummy)

Message('Test File Name', strFullName)
exit


This the 'GetFinalPathNameByHandleA' function is only available on Windows Vista and newer versions of Windows.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

fhammer

It worked. Thanks for the code sample.

Note: In the DllCall I had to change "long_ptr:hFile" to "long:hFile".

I got error "1378 DllCall: Bad parm code. Only WORD, LONG, LPSTR, LPBINARY or LPNULL" with the original.

Thanks again!!

td

Quote from: fhammer on January 26, 2019, 10:44:08 AM

Note: In the DllCall I had to change "long_ptr:hFile" to "long:hFile".

I got error "1378 DllCall: Bad parm code. Only WORD, LONG, LPSTR, LPBINARY or LPNULL" with the original.


That must be because you are using an older version of WinBatch. "Long_ptr" was added in 2018B.  "Long_ptr" allows you to use the same script with both 32-bit and 64-bit WinBatch because handles are 64-bits long on 64-bit systems.   Most kernel32 and user32 handles only have 32 bits of significant data on 64-bit Windows systems when used with 64-bit WinBatch but not all 64-bit system handles restrict themselves to only 32 bits of significants.  So using "long_ptr" with 2018b or newer is the best option.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

stanl

Curious.  Tony, your code referenced Intcontrol 94 - which appears to only apply to fileopen() - so you already know the name of the file. This begs the question as to where the OP obtained the file handle in the first place. I bring this up because I saw a reference to NTDll.lib and NTQueryObject() function.

Didn't realize that lib was available on my Win10 laptop under Program Files (x86). It is undocumented here

http://undocumented.ntinternals.net/index.html?page=UserMode%2FUndocumented%20Functions%2FNT%20Objects%2FType%20independed%2FNtQueryObject.html

and looks like it has a lot of usefulness. So, without mudding up this thread, would like to test if that function can be called from WB.

td

I think you missed the point of the example script.  Fhammer did not state the type of file handle that a file name was needed for.  It could have been either a WIL file handle or a Win32 file handle.  The point of using IntControl 94 was to obtain a Win32 handle to test the DllCall and not to obtain the name of a file opened with FileOpen.  That said I can imagine scenarios where it would be necessary to obtain the name of a file even if you originally opened the file using the name.  The example is intended to demonstrate obtaining the file name no matter the purpose nor the type of file handle.

The Ntdll.dll has been around since Windows NT - hence the name.  The function NTQueryObject() is part of the WDK used for developing Windows device drivers. Many WDK functions have both user-mode and kernel-mode versions.  You can't easily call the kernel-mode version from WIL because WinBatch is a user-mode program.  User-mode (assuming this function because it is listed under system services is user-mode callable) and kernel-mode versions of WDK functions can produce different results so I won't hazard a guess as to the outcome of attempting to call the function using DllCall. 

I do question the notion that it is somehow "hidden".  See the MSFT documentation:

https://docs.microsoft.com/en-us/windows/desktop/api/winternl/nf-winternl-ntqueryobject

"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

td

For what it's worth the WDK header file has the following comment regarding the NTQueryObject() function,

//
// use the Win32 APIs instead
//     GetFileInformationByHandle
//     GetFileInformationByHandleEx
//     GetProcessInformation
//     GetThreadInformation
//     
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

stanl

Point taken. Your initial response mentioned there may be an easier way, then you noted the OP may not have a recent WB distro. I was just curious if NTQueryObject() might be worth looking at and obviously it isn't.