Documentation of IFPORT::GETFILEINFOQQ

[ivfuser]

Hi.

The following text appears in the library reference:

egin{extended_quote}
To get information about one or more files, set the handle to FILE$FIRST and call GETFILEINFOQQ. This will return information about the first file which matches the name and return a handle. If the program wants more files, it should call GETFILEINFOQQ with the handle. GETFILEINFOQQ must be called with the handle until GETFILEINFOQQ sets handle to FILE$LAST, or system resources may be lost."
end{extended_quote}

What kind of system resources? I'm guessing file handles, but would like to know for sure.

Thanks.

[Steven_L_Intel1]

Well, I think this text is a bit dated - Windows 98 and earlier had "resources" which were fixed in number and could be exhausted. NT/2000/XP don't. But it's good advice to follow anyway.

[ivfuser]

Thanks, Steve.

[Paul_Curtis]

Here is the Win32 way of geting file information; note that the call to FindClose is required to avoid a memory leak. The memory leak is associated with the T_WIN32_FIND_DATA object which is allocated by Windows, and is probably what the quoted text is referring to. It is much better to use the Win32 functions where these issues can be dealt with explicitly.

Code:

! TYPE T_WIN32_FIND_DATA
! SEQUENCE
! integer(DWORD) dwFileAttributes ! knowns DWORD 
! TYPE (T_FILETIME) ftCreationTime ! typedefs FILETIME 
! TYPE (T_FILETIME) ftLastAccessTime ! typedefs FILETIME 
! TYPE (T_FILETIME) ftLastWriteTime ! typedefs FILETIME 
! integer(DWORD) nFileSizeHigh ! knowns DWORD 
! integer(DWORD) nFileSizeLow ! knowns DWORD 
! integer(DWORD) dwReserved0 ! knowns DWORD 
! integer(DWORD) dwReserved1 ! knowns DWORD 
! character(260) cFileName
! character(14) cAlternateFileName
! END TYPE

	FUNCTION file_exists (fname) RESULT (size)
		IMPLICIT NONE
		TYPE(T_WIN32_FIND_DATA)	:: fdata
		CHARACTER(LEN=*),INTENT(IN)	:: fname  ! full pathname to file
		INTEGER				:: size, handle, rval
		size = -1
		handle = FindFirstFile (fname,fdata)
		IF (handle /= INVALID_HANDLE_VALUE) THEN
			size = fdata%nFileSizeLow
			rval = FindClose (handle)
		ENDIF
	END FUNCTION file_exists

[ivfuser]

---

Paul-Curtis wrote:

Here is the Win32 way of geting file information; note that the call to FindClose is required to avoid a memory leak.

---

Ah. This is good. I've been using the portability library as a bit of a crutch when I have to port to Windows. Thanks for the insight and a detailed alternative.

[aaron_birenboim]

I have tried:

USE DFLIB
USE IFPORT
USE IFCORE

no help.

Any suggestions on IVF 11 methods to do this?

[aaron_birenboim]

oops I goofed. lost first part of post.

It seems that GETFILEINFOQQ was in IVF9, but not in IVF11.

I now get the error:

...gfildate.f(47): error #6284: There is no matching specific function for this generic function reference. [GETFILEINFOQQ]
compilation aborted for ...gfildate.f (code 1)

I have tried combinations of:
USE DFLIB
USE IFPORT
USE IFCORE
but they did not help.

How might I get similar functionality in IVF 11?

[Steven_L_Intel1]

Because you get this particular error, that tells you that the problem is not a missing USE. It sees a generic declaration for GETFILEINFOQQ but your call doesn't match it. Unfortunately, you did not show the code calling the routine and the declarations of the arguments.

I'm going to make a guess, though. You're building a 64-bit application and have specified an INTEGER*4 variable for the HANDLE argument. Declare this to be INTEGER(INT_PTR_KIND()) instead and it should work.

[John4]

Quoting - Steve Lionel (Intel)

Because you get this particular error, that tells you that the problem is not a missing USE. It sees a generic declaration for GETFILEINFOQQ but your call doesn't match it. Unfortunately, you did not show the code calling the routine and the declarations of the arguments.

I'm going to make a guess, though. You're building a 64-bit application and have specified an INTEGER*4 variable for the HANDLE argument. Declare this to be INTEGER(INT_PTR_KIND()) instead and it should work.

I have a problem related to this particular function. When I use it on a 32-bit machine, it works just fine, but on a 64-bit machine it never returns FILE$LAST (so I have to use FILE$ERROR as a condition to exit the loop).

It seems to me that some of the kinds for the INTEGERs defined in IFPORT are not set properly; or that the procedures' arguments were not modified for the 64-bit version ---e.g., JHANDLE_SIZE is set to POINTER_LEN but, the compiler throws a warning for the second argument of PXFSTRUCTCREATE (and the warning goes away when such argument is defined as INTEGER(4)).