File Handling Errors

We've built an application which relies heavily on ClearWin functions such as Rename@ and Erase@. We call DosErr@ after these functions are used to handle any problems encountered. Increasingly over recent years we've had more and more of our customers getting one of these error pop-ups:

• 'Cannot create a file when that file already exists'
• 'The system cannot find the file specified'
• 'Process cannot access the file because it is being used by another process'

Are these error messages being seen in other people's programs?

What are the common causes for these errors, i.e. what's causing the function to fail?

We suspect that when computer resources are being heavily used that (for example) an Erase@ command may take a long time to finish so that when a Rename@ command is used on the next line, the file we're trying to erase hasn't actually been erased yet. Does this seem like something that could happen, and if so, what can we do to prevent it?

We really like using ClearWin, but these errors are becoming a serious problem for our customers. The people reporting this problem seem to be using older computers with Windows XP and 4 GBRAM, but requiring all of our users to get a hardware upgrade would not be a popular solution!! Any advice or thoughts would be most appreciated!

Clay Jones

I have seen instances where it would appear that the file, having been deleted, is not actually deleted. It does appear that the newer, faster processors are out stripping the ability of the application to act as truly single threaded. I also see this kind of behavior when presenting windows/dialogs (ClearWin+).

I have also seen the effects of closing a file, then immediately re-opening it and having the reopen fail because the file is still being used by the OS (or whomever) and not yet relinquished.

While I can't swear to it, that's what it looks like.

I no longer use 'NEW' for a file, but use 'REPLACE'. This has solved many problems with files not quite getting deleted (or closed).

One way to ensure that the file is truly deleted is use FEXISTS@ to see if the file is still there before you continue. Loop (for a while) until it is no longer there, then continue. I do something similar when I get an error that a file is in use, I loop for a pre-set number of times waiting for the file to become un-used, it then opens just fine. And, it happens all the time.

In this context it might be helpful to call sleep1@ for a small number of milliseconds within the 'while loop' mentioned above.

There are several possibilities to delete a file. Immediately after closing the file can be done with close(10,status='delete') or closefd@ for files opened with openr@ or openw@. Further, instead of erase@ you can use DeleteFile from Windows (I prefer this). I'm not sure whether the time for deletion is the same in all cases, so you may try different ways.

Wilfried

Just to be pedantic, RENAME@ and ERASE@ are DOS functions, present in FTN77 and carried over into FTN95 with nothing to do with Clearwin+ You don't find equivalent convenient routines in many other Fortran compilers, and even if you did, they would display the same behaviour in accessing such fundamental OS functions..

It looks like one of the jobs you do is to delete a file with a specific name, and then immediately afterwards open a different file with that particular name. You clearly don't want any of the original contents and you clearly want to write to it, because a file just opened will be empty.

So why don't you simply REWIND it?

As for RENAME@, you just rename a file then immediately afterwards, open another file with the original name. Why? Is there something of specific significance about the original name?

Surely, the correct procedure is to get a unique file name using TEMP_FILE@ when opening it, and RENAME@ that when you have finished with it. After all, Fortran only knows about the logical unit number after the OPEN statement has been executed, and the LUN is immediately available for a different file after the original one has had a CLOSE executed - regardless of how asynchronous windows might be dealing with delete and rename requests.

Eddie

... and, while I'm at it, if the file you want to RENAME@ has just been filled by your application, and the renaming is a way of saving its contents, why don't you open it for writing with its intended final name?

Eddie