Why is open(1,file='foo.dat') looking in c:windowssystem32 ?

[mirko_vukovic]

Hello,

I have several open statements such as
open(1,file='materials.dat'). The code crashes because it looks for the files in c:windowssystem32.

That directory is in my search path. But the files are present in the directory from which I am invoking the program. I tried different file extensions, and that did not help. I can fix the problem if I specify the full path.

I spent an enjoyable (yeah, right) few hours going over the documentation and my set-up (search path, environment variables, files), trying to figure out why that may be, and can't figure it out.

I am using ifort10 on WindowsXP via the command line interface (cygwin). (I will soon move this development work to linux)

Thanks,

Mirko

[Steven_L_Intel1]

I don't know how cygwin executes programs. It may not change the default directory and run from some standardized one such as windowssystem32. Normally when you run Windows executables by double-clicking on the EXE, the default is the same directory as the EXE. If you run from a command line I think the default is whatever is set for the command prompt's shortcut.

In any case, it seems that your program is being run with C:WindowsSystem32 as the default directory. This is not under the control of Fortran, so you need to figure out how to change that in the Cygwin environment.

[mirko_vukovic]

Steve,

You were right. When I tried to run from the windows command prompt, it ran from the parent directory (i.e. not c:windowssystem32).

I will take this discussion to cygwin, and post a resolution (for future reference)

Thanks,

Mirko

[TimP]

A normally installed cygwin would never use windowssystem32 unless specifically asked to do so. The FAQ warns specifically against bypassing normal installation procedures and placing cygwin components in Windows system paths. Possibly this could be made to happen indirectly by decorating ifort so as to make it run under cmd.exe, but I've never heard of anyone trying that. If someone goes to the cygwin list and wants help, they will be told to do things in supported ways, and no one supports even sane ways of running ifort under cygwin.

[mirko_vukovic]

Tim,

I don't have the cygwin.dll (or any other components) in windowssystem32. I installed (& updated) my cygwin installation in the recommended way.

btw, the way I set up ifort environment for cygwin is to call ifortvars.bat from the cygwin.bat file before launching bash:

@call C:program filesintel...ifortvars.bat
chdir e:cygwin-rootin
set CYGWIN=...
bash --login -i

Thanks,

Mirko

[mirko_vukovic]

Tim

Here is a reply to my question posted on the Cygwin mailing list:

To implement POSIX functionality like allowing to remove the current directory, Cygwin changes the Win32 current working directory of a process to C:WINDOWSsystem32, while keeping its own notion of what the CWD is. This is transparent to the Cygwin file IO calls, but will confuse the Win32 calls.

The CWD is inherited by child processes. When invoking non-Cygwin programs, Cygwin's exec() should change the cwd back to its real value. That doesn't seem to be happening in your case.

To which I replied:

I think that there is some evidence of intermittent behavior that may have been recently introduced into cygwin (The following is from memory and should be taken as anecdotal evidence only):

When I ran the code for the first time yesterday, it ran fine. I then downloaded gdb with the new setup.exe (I thought I could use it for debugging the code), and after that I started having the aforementioned problems.

So, I wonder if there was a recent change to the cygwin code that caused this problem.

So, for now I am switching to window's command prompt.

Mirko

[mirko_vukovic]

Here is a bit more data: The code behavior depends on compilation switches.

With a plain "ifort source.f" command, everything runs fine.

If I set /Od or /debug:full, it looks for files in the system directory, and also sets some uninitialized and undeclared variables to non-sensical values.

(I have inherited this code, and it obviously does not follow good coding practice: It uses exclusively implicit statements for variable declaration, and also shares all the common blocks among *all* the subroutines. It is an example of a poorly designed f77 code)

[Steven_L_Intel1]

That suggests you have a coding error in the application which is referencing memory outside declared variable bounds. First, try compiling with /check:bounds/gen-interface/warn:interface and see what you get.

[mirko_vukovic]

You were right Steve. I found a few out-of bounds references. It will be fun fixing them.

Thanks.

Mirko