Severe Error (29) on Open() for Network files

[albrecht]

I am trying to OPEN a network file using Visual Fortran 9.x on a Windows 2003 server.

I have tried setting permissions for "everyone" to all, but to no avail. I have no trouble opening / reading / writing / closing local files. The error I get is a "file not found" error (29). This is spurious, as I am opening "unknown", but just in case I copied the file there and tried the open() command with the same error resulting.

Example: filename 'C:ob.txt' will open fine, whereas 'G:ob.txt' will not.

I have tried using the non-logical name of 'G:' as well.

Is this not possible?
Is there some parameter(s) I have not set?

Thanks for any help.

John Albrecht

[Steven_L_Intel1]

It is possible and there is no "parameter" to set - at least not on the Fortran side. The Windows file system is reporting the error. You could try calling GETLASTERRORQQ to see what the most recent system error code was and then look that up in the Win32 error code list.

[albrecht]

GETLASTERRORQQ returns 0 (no error). I made both a test program and modified the actual program that is failing. In both cases when I use debug and step through the code, the OPEN() works. Installing the debug version of the file does not solve the problem.

It would appear that there is a user privilege problem, i.e. the installed program is not allowed to open a file that I am allowed to open when running in debug.

Testing this theory, I tried setting the uppermost level of the share that I have available to me to have full access to "everyone". The user which owns the debug process (which works) is the same as the installed program (which doesn't work). This user has full administrator access to the network disk (meaning my change for "everyone" should not have made a difference, which it didn't).

What can I try next?

Thanks,
John Albrecht

[Jugoslav_Dujic]

Have you tried printing (storing to a file) the result of GetLastError() in the setup where it fails?

It is common that runs inside and outside the debugger behave differently due to uninitialized variables, but affecting the OPEN statement is quite unusual. Is "Array bounds checking" enabled in the deployment which fails?

One possible (but again, unlikely) explanation would be that drive G: is not mapped in the context of the calling user. Can you read anything from G:?

[Steven_L_Intel1]

I suggest trying as an experiment coding a call to the Win32 API routine CreateFile and see what its return status is.

[albrecht]

I wrote the result of GetLastError() to a file in yesterday's attempts. Sorry I wasn't clear about that. Situation is the following:

- In debug (interactive) mode, stepping throught the code, the network file g:ob.txt can be opened. No problems.
- In detached (spawned) "debug" or "release" mode, installed as a scheduled task, the file g:ob.txt can not be opened. In the code I jump to an label for errors, and do a GetLastError() when this happens. The returned value (Integer*4) is 0. Always.

Regarding "array bounds checking": Yes and no. I did some recursive testing yesterday where I toggled a lot of compiler/linker options and tested after each change (obviously to no avail). I have been programming in Fortran for over 20 years, but only 1 year on Windows in .NET, and there are a lot of switches that I freely admit I don't know. (old dog / new tricks...)

In all modes, the user name is the same, but I wonder if all is REALLY the same. On old DEC machines, even if the user was the same, a detached process (spawned) had different privileges and priorities than an interactive (as in stepping debugging) process. This resulted in detached processes not being allowed (by default) to do all the same things as the interactive user could. One had to use an administrator account to change the privileges and priorities of the detached processes.

This problem seems to be just that sort of problem, but I have no idea if Windows has such functionality, nor how to administer it if it does.

Anyway, thanks for the help. Any other ideas? I see there is another message from Steve Lionel with an idea.

John

[albrecht]

Problem solved: I'd like to say that the problem was some obscure windows parameter, but it appears to have been a typo.

I recoded the network file name, and this time it worked. I know the string was 56 characters when it failed. It is now 55. I don't have a VSS version to see what I typed wrong, but I remember numbers extremely well, and I'm sure it was one character more before.

Well, as they say, "All well that ends."

Thanks very much for the help. I would still like to know why I got no error from lasterrorqq, but I don't have the time to investigate.

Best regards,
John Albrecht