File existence VS invalid file path names

[Evan_de_Kock]

Hello,

When usingan INQUIRE statement such as INQUIRE(FILE=FileName, EXIST=Q, IOSTAT=IERR), or functions from the IFPORT portability module that involves FileName (e.g. STAT() andACCESS()), then the error codes returned in the case of a failure caused by an invalid file path name FileName does not reflect the fact that the FileName is invalid - in fact, the error codes simply indicate that the file does not exist. Surely there is a non-pedantic difference between an invalid file name (e.g., FileName = 'C:\testdir\?*<>testfile') and the non-existence of a file as specified by a valid file name?

The only way Ihave establshed to makesuch a distinction is to try and OPEN the file and then toexamine the IOSTAT error code valueto see if the value FOR$IOS_FILNAMSPE (error code 43) or FOR$IOS_FILNOTFOU (error code 29) is returned. This misuse of the OPEN statement is clumsy and obviously not very efficient. It also raises the following question: how portable is the use of the parameters such as FOR$IOS_FILNAMSPE and FOR$IOS_FILNOTFOU as specified by the 'for_iosdef.for' file?

Basically, my main question is why can't the IFPORT functions such asSTAT() andACCESS()return an error code separate fromthe error codeENOENT to indicate that the file name is invalid? Similary, why can't the INQUIRE statement provide a FOR$IOS_FILNAMSPE IOSTAT error code if the file name is invalid?

Regards
Evan de Kock

[jimdempseyatthecove]

Evan,

Until you get a more formal answer, maybe you can use GetLastError to examine the last error code (Use SetLastError(0) to flush any prior error code if necessary before your call with questionable path).

Jim Dempsey

[Steven_L_Intel1]

For INQUIRE, I would not expect that level of detail. When you ask if a file exists, INQUIRE correctly returns "no" if the filename is invalid because it doesn't exist by that name. IOSTAT should be set only if something prevented INQUIRE from completing the task.

You might consider GETFILEINFOQQ for this purpose.

[Paul_Curtis]

Evan,
I cannot comment on how IFPORT works, but Windows makes no distinction between filenames and pathnames, and the same function is used to determine the status of both. Here is sample code from a function which queries the availablity of a path (only, no filename included), prior to file i/o in that location, and a negative result indicates a problem with the specified path. If the path is ok, the same API function can then be used with a complete filepathname argument and this time the result will pertain to the file. There is no separate Windows error code for path problems vs filename problems, and so I doubt that IFPORT, which in its Windows mode must use a similar approach, would create such a distinction.

[cpp]CHARACTER(LEN=256)				:: pathname
INTEGER(HANDLE)                 :: handl
TYPE(T_WIN32_FIND_DATA)			:: fdata
netpath_ok = .FALSE.

handl = FindFirstFile (pathname, fdata)
netpath_ok = (handl /= INVALID_HANDLE_VALUE)

IF (netpath_ok) THEN
	nc = FindClose (handl)		! release system resources
ELSE
   ...	
[/cpp]

[bbradley]

Here is an old MsDos trick for detecting a path name:

Logical DoesIt

Inquire ( File = 'c:DataNul.', Exist =DoesIt )

Write (*,'(a,L4)') ' Does DataNul. exist ?', DoesIt

If an emptyfolder named Data is created, the above will show a "T" when the above is
executed.

[Evan_de_Kock]

Quoting - bbradley

Here is an old MsDos trick for detecting a path name:

Logical DoesIt

Inquire ( File = 'c:DataNul.', Exist =DoesIt )

Write (*,'(a,L4)') ' Does DataNul. exist ?', DoesIt

If an emptyfolder named Data is created, the above will show a "T" when the above is
executed.

I believe that the problem of differentiating between and invalid file name (full file path name) and a non-existing file lies within the IFPORT module and has nothing to do with Windows.For example, the IFPOSIX routinePXFACCESS() returns the error code EINVAL if the file name is invalid and ENOENT if the file does not exist (althoughIntel's documentation states that it only returns ENOENT). However, not all the IFPOSIX routines are so helpful. For example, PXFSTAT returns ENOENT when the file does not exist and also when the file name is invalid (i.e., the same behaviour as the STATfunction from IFPORT). Thus, if one is using the PXFSTAT or STAT routines and an error code ENOENT is returned, then one is forced to call PXFACCESS if you want to make sure that an invalid fine name is not at stake.

Incidently, the ACCESS routine from the IFPORT module behaves just like PXSTAT and STAT since it only returns ENOENT. Thus, the behaviour of ACCESS and PXFACESS are not consistent with each other (fortunately) with regards to the treatment of invalid file names and non-existent files.

Evan