Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.

Disk file access errors

dondilworth
New Contributor II
846 Views
I compile my program on Windows 7 with Fortran Composer XE 2011. It reads and writes many disk files. When I install that version on a Windows XP machine, everything works fine.

But on another Windows 7 machine, I get errors whenever the program tries to write to a disk file that was already there (created by the previous version). It says the files are all "read only". That is nonsense; the file properties dialog does not have the read-only box checked, and the previous version can still read from and write to them.

Then it complains that the open and close were inconsistent. That, too is nonsense. Here is an example (LL is a character*13 string):

Reading:

CLOSE(59)
OPEN(59,FILE=LL(LNUM),FORM='FORMATTED',STATUS='OLD',ERR=50)
REWIND 59

Writing:

CLOSE(UNIT=59)
OPEN(59,FILE=LL(J),FORM='FORMATTED',STATUS='UNKNOWN',ERR=300)

Do you see anything inconsistent about this? How can I make it work? The message is "Serious error (46) unit 59"
0 Kudos
4 Replies
Steven_L_Intel1
Employee
846 Views
The error message you show is coming from the application, so that's not too helpful.

I've sometimes seen on Windows that a close followed immediately by a reopen of the same file will fail because Windows, behind the scenes, hasn't completely closed the file. In these cases, adding a small delay between the two solves the problem. You could, for example, insert:

CALL SLEEPQQ(200)

after the CLOSEs and see if that helps. This will insert a 200msec delay.
0 Kudos
bmchenry
New Contributor II
846 Views
Another thought:
Where are the files located? In Program Files\your installation directory??
Or any other restricted access directories?
Win7 complains if you don't have administrator permission and/or if you aren't the owner of the file.
For example, if YOU copy a file from another machine who's the owner on the new machine?
YOU or your name from the other machine?
To avoid these issues we make a point of having separate directories for any files used by our programs to avoid the 'ownership'/administrator related issue.
0 Kudos
dondilworth
New Contributor II
846 Views
Yes; these replies all point to the cause. I tried running the program on the new machine in Adminstrator mode, and it worked fine. So that's one extra step for the user, but, hey.



0 Kudos
Steven_L_Intel1
Employee
846 Views
I would strongly suggest either moving the program out of Program Files, or modify the code to create its files in the user's My Documents folder or some other user folder, not write them under Program Files. You may find that antivirus products interfere with programs that write to files under Program Files.
0 Kudos
Reply