closing and releasing output files on windows

[Scott_L_]

I had understood that IO on windows OS allows the process writing and closing an ascii file to continue before the IO operation was complete.   We often see a program run, write out a file, but when the next process tries to write to the same file, the file is locked or the write fails.   What I am seeing now is building the exe in debug mode, the program  runs fine and completes.  When I run the same source and data in Release mode build, the program gets to its completion when it should be done and exiting, I see a windows pop-up saying _.exe has stopped working: a problem caused the program to stop working...

I am wondering if I am interpreting this reasonably, and if there is some function I can access to wait until all pending windows IO operations are complete before continuing the process.

running on windows 7 or 10, visual studio 2015 and ifort 17.1.

thanks

[Steve_Lionel]

My experience with this is that debug vs. release makes no difference. What I find helps is to add a half-second delay after the CLOSE (use SLEEPQQ). There is nothing I know of that you can do to wait for Windows to close the handle.

[FortranFan]

Have you tried FLUSH statement?

Don't know if it will help you but I vaguely recall a colleague at my work or some reader here finding it to be useful.

[Steve_Lionel]

It isn't an issue with writing data to disk. Rather, after the CloseHandle function is called by the I/O library, Windows doesn't release the file for a short time after the call returns.

[jimdempseyatthecove]

An additional contributing factor can be your Anti-Virus program scanning the (newly created) output file. If this is the cause, you can specify that the output folder is not to be scanned.

Also, the short delay that Steve referenced (lazy write/filesystem update) becomes longer at times of high file I/O. So the short delay you use during testing may be insufficient later under other runtime conditions.

If possible, you can insert code to test to handle OPEN failure to delay, then repeat the OPEN (indicate true failure after a few attempts).

Jim Dempsey

[Scott_L_]

Thanks for the great info.

I had forgotten about virus scanning.  I will look into whether we can disable it or not.

We do make repeated attempts to write to output files after the first program completes.  I was hoping to be able to eliminate that but I guess not.

Lastly, my thought that the error pop-up I saw only on windows Release mode turned out to be my fault and nothing to do with file IO.  I assigned values to an allocatable array in a derived type that I hadn't allocated.  Even with this error, it ran and produced correct output on Linux/Release and windows/Debug (with range checking) with intel fortran 17.1, but faulted on windows/Release.  I found be deallocating the derived types I could get a heap error which lead me to find the problem.   Just to note that ifort range checking did not catch my blunder of assigning values to an unallocated array.   You can argue the that isn't range checking's job to catch assigning values to unallocated arrays, but it would be nice if it did or some other Debug check did.  Perhaps newer releases have this capability. 

Thanks again.

[Steve_Lionel]

/check:pointer should detect accessing an unallocated array.

[Scott_L_]

I believe you, but I did have /debug:full on in debug mode.  In my application, in ifort 17.1, windows 7, VS 2015, this error did not get trapped.  If this wasn't the case in 17.1 and version 19+ do support this detection, then maybe I can convince the management to invest in validating our software on a later ifort version.

thanks again.

[Steve_Lionel]

/debug does not control run-time checks - that affects only the amount of debugging information available. If I recall correctly, /check:pointer is not on by default in a Debug configuration.

[Scott_L_]

You're right again.  I did have /check:all on which I would have thought turned on check for null pointers and allocatable references, (/check:pointer). 

[Steve_Lionel]

Yes, it should.