Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.

Issue with INQUIRE OPENED=

jim_cox
Beginner
1,730 Views

I have a problem with the OPENED specifier of INQUIRE not correctly returning whether a file is open....

Working in the debugger, with the working directory set to 'D:\TestData\Northshore\2B\

CHARACTER*260 SBUFF
LOGICAL ISOPEN
INTEGER*4 IERR
INETEGER*4 NUM

IF I call

INQUIRE (FILE=SBUFF, OPENED=ISOPEN, IOSTAT=IERR)

when SBUFF = 0112VT.000

ISOPEN returns .FALSE.



But when SBUFF= D:\TestData\Northshore\2B\0112VT.000

ISOPEN returns .TRUE.


In both cases IERR returns 0


The file in question actually is open as INQUIRE ( FILE=SBUFF NUMBER=NUM) correctly returns NUM=1400


Compiler version is: Intel Visual Fortran Compiler Integration Package ID: w_cprof_p_11.1.048

Is this a known issue?



Thankx again

Jim

Getting there slowly....


0 Kudos
1 Solution
bmchenry
New Contributor II
1,730 Views
'working' v 'current' directory.
just a simple as inserting the full path name into the INQUIRE, you could also check to see what is the 'current' directory and if it is the same as the expected 'working' directory.
During program execution there is no guarantee that the 'current' directory will remain your expected 'working' directory.
The 'current' directory can change depending on how you start the program (from the IDE, in debug or release), from a dialog from a control program located at some directory in the windows world, etc. etc.

View solution in original post

0 Kudos
10 Replies
Paul_Curtis
Valued Contributor I
1,730 Views
You seem to have answered your own question -- make sure your filenames comprise the complete path as well as the name+ext. "Working directory" is a fiction which died with MS-DOS.

Your program can easily determine on startup the directory path to the program's executable, assuming that may bear some relation to the location of other files which will be referenced. Here is how you get the complete originating path to your program, returned in string fpname:

nc = GetModuleFileName(GetModuleHandle('yourprogram.exe'C), fpname, LEN(fpname))
0 Kudos
jim_cox
Beginner
1,730 Views
Quoting - Paul Curtis
You seem to have answered your own question -- make sure your filenames comprise the complete path as well as the name+ext. "Working directory" is a fiction which died with MS-DOS.

Your program can easily determine on startup the directory path to the program's executable, assuming that may bear some relation to the location of other files which will be referenced. Here is how you get the complete originating path to your program, returned in string fpname:

nc = GetModuleFileName(GetModuleHandle('yourprogram.exe'C), fpname, LEN(fpname))


The term "working directory" comes directly from the project's "configuration properties"

If it is a fiction, how come I could open the file with just a local path?

And how come the NUMBER= specifier works as expected?

According to the fortran manual Inquire entry

"The name can be any pathname allowed by the operating system"

Thankx for the tip on finding the excutable, but unfortuantely in my case the exe will almost certainally be in a different directory to the data files

I think I'll just use a workaround and check for a valid file number rather than to going through the code coverting evrything to fullpath reference....

0 Kudos
DavidWhite
Valued Contributor II
1,730 Views
Quoting - jim.cox


The term "working directory" comes directly from the project's "configuration properties"

If it is a fiction, how come I could open the file with just a local path?

And how come the NUMBER= specifier works as expected?

According to the fortran manual Inquire entry

"The name can be any pathname allowed by the operating system"

Thankx for the tip on finding the excutable, but unfortuantely in my case the exe will almost certainally be in a different directory to the data files

I think I'll just use a workaround and check for a valid file number rather than to going through the code coverting evrything to fullpath reference....


Jim,

I'm with you on this one. If the Unit Number is allocated correctly, then the OPENED status should be correct irrespective of whether the full path is specified or not. If the full path is required, then it should be required all the time not sometimes. This should be flagged as a bug.

David


0 Kudos
Steven_L_Intel1
Employee
1,730 Views
I think this ought to work, and I disagree that "working directory" is no longer a useful concept. I'll do some tests of my own and escalate this if need be. The way it "ought" to work, based on my having implemented exactly this feature for VAX Fortran some 30 years ago, is that the filename given in INQUIRE is "expanded" to what it would be if the file were opened and the resulting expansion compared to the full path of opened files. Of course, that was on VMS where there was a straightforward way to do that with system calls - I'm not so sure about Windows/Linux/OS X.
0 Kudos
Paul_Curtis
Valued Contributor I
1,730 Views
... I disagree that "working directory" is no longer a useful concept. I'll do some tests of my own and escalate this if need be. The way it "ought" to work, based on my having implemented exactly this feature for VAX Fortran some 30 years ago, is that the filename given in INQUIRE is "expanded" to what it would be if the file were opened and the resulting expansion compared to the full path of opened files. Of course, that was on VMS where there was a straightforward way to do that with system calls - I'm not so sure about Windows/Linux/OS X.

No program in any operating system opens a file using only the name, and this would appear to "work" in fortran only for the special case where the data files happen to be in the same path as the executable. MSDOS retained the path info behind the current system prompt, and would automatically pre-pend that info onto any filename before executing a system command involving the file; that seems to be your take on VMS as well. My example shows that it is easy to get this information in Windows, and it is further prudent to use it.

0 Kudos
Steven_L_Intel1
Employee
1,730 Views
Windows has the same concept of current or working directory as does VMS, Linux, UNIX and probably many other operating systems. There is a default of the same folder as the EXE is located, but that can be overridden in many ways - through shortcuts, or in Visual Studio, it sets the project folder as the default but lets you change it in project properties. There are also system calls you can make to change the current directory.

INQUIRE should do exactly what OPEN does in terms of identifying where a file is to be created (actually, Windows handles this on its own.) In the case of INQUIRE, it needs to figure out what that default is and how it combines with any relative or absolute path given in the FILE= specification.
0 Kudos
bmchenry
New Contributor II
1,731 Views
'working' v 'current' directory.
just a simple as inserting the full path name into the INQUIRE, you could also check to see what is the 'current' directory and if it is the same as the expected 'working' directory.
During program execution there is no guarantee that the 'current' directory will remain your expected 'working' directory.
The 'current' directory can change depending on how you start the program (from the IDE, in debug or release), from a dialog from a control program located at some directory in the windows world, etc. etc.
0 Kudos
jim_cox
Beginner
1,730 Views
Quoting - bmchenry
'working' v 'current' directory.
just a simple as inserting the full path name into the INQUIRE, you could also check to see what is the 'current' directory and if it is the same as the expected 'working' directory.
During program execution there is no guarantee that the 'current' directory will remain your expected 'working' directory.
The 'current' directory can change depending on how you start the program (from the IDE, in debug or release), from a dialog from a control program located at some directory in the windows world, etc. etc.


I think you may well be right

The ONLY way I have been able to get my code to work reliably is to do a FULLPATHQQ before calling INQUIRE



0 Kudos
IanH
Honored Contributor III
1,730 Views
Quoting - bmchenry
During program execution there is no guarantee that the 'current' directory will remain your expected 'working' directory.

Perhaps just a mis-wording, but under Win32/64, while a process (or a program) is executing (after it has been created) there is a pretty strong guarantee that its current directory will only change if the process requests it somehow.

At the windows API level the functions that could result in a change in a process' current directory are pretty well documented (SetCurrentDirectory obviously, less obvious are side effects from the file dialog box APIs, etc). At the fortran level I'd very much hope that you'd have to be calling something equally explicit - it would be poor form if an OPEN statement permanently changed the current directory, for example.

If your program starts with the current directory being as expected, then it should stay that way, unless your program dictates otherwise. What the current directory is when your program starts is a different question.
0 Kudos
Paul_Curtis
Valued Contributor I
1,730 Views
Quoting - IanH
...If your program starts with the current directory being as expected, then it should stay that way, unless your program dictates otherwise. What the current directory is when your program starts is a different question.

Fortran file i/o reflects a simpler time long, long ago when the closest concept to "current directory" was "has the sysop mounted your mag-tape correctly". The world has become more complex, but the solution is simple: interrogate the system to find the exact path to the executable, and then make sure that all file i/o is done with complete and explicit pathing. Expected default behavior is not reliable.
0 Kudos
Reply