- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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"
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"
Link Copied
4 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page