buffered IO

[Scott_L_]

The code I am working on is running fine on Windows.  When it is ported and  built on Linux, it fails on the  on eof our unit tests  with an error  – cannot write a file to working directory - in a directory that is open to write in.

Running the same Linux executable with strace, I get "too many open files" error trying to write the file.

Changing all buffered IO open statements from BUFFERCOUNT=4 to =1, now it runs with no errors.   Is there any known issue with buffered IO on Linux as opposed to WIndows?

thanks,

Scott

[Kevin_D_Intel]

I reproduced the behavior described; however, on Linux I'm finding that it does matter that files are present in the lower level junk2* subdirectories. When all junk2* subdirectories are empty the entire directory tree "junk" is removed. On Windows, everything is removed with and without files present at that lowest level. I reported this to Development and will let you know whether there's a work around.

(Internal tracking id: DPD200419358)

[Kevin_D_Intel]

Development confirmed there is a defect in the Linux implementation of GETFILEINFOQQ preventing recursive usage. This will be fixed in a future update.

[Scott_L_]

Thanks for your help Kevin.   I just want to confirm something about static/automatic locals in recursive routines.   I am compiling with the global compiler option /save for legacy routines relying on it.  Where I have functions or subroutines declared recursive, does ifort force all local variables in that routine to be automatic in spite of the global compiler option /save?   It seems to work this way, but wanted to be sure.  Adding AUTOMATIC to the test routine did not seem to change anything.

thanks again.

scott

[Kevin_D_Intel]

Yes, as advertised https://software.intel.com/en-us/node/678268