Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
26733 Discussions

closing and releasing output files on windows

Scott_L_
New Contributor I
381 Views

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

0 Kudos
10 Replies
Steve_Lionel
Black Belt Retired Employee
363 Views

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
Honored Contributor II
356 Views

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
Black Belt Retired Employee
342 Views

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
Black Belt
324 Views

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_
New Contributor I
314 Views

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
Black Belt Retired Employee
312 Views

/check:pointer should detect accessing an unallocated array.

Scott_L_
New Contributor I
290 Views

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
Black Belt Retired Employee
277 Views

/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_
New Contributor I
268 Views

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
Black Belt Retired Employee
248 Views
Reply