Random error 70 on repeated open/close

[Claudio DalZovo]

In some apps that open and close many times the same file (for example within a loop) I get randomly an error 70 "Permission denied" on Open (for output or append).

It seems that sometimes the "close" statement isn't immediately executed by the operating system, so the next "open" find the file still "opened".
No doubt the code is correct, as it works without errors most of times.

Trapping error 70 and resuming the same statement after a small pause, the statement works fine in most cases ... but this of course slow down the application.

Files opened/closed are on a network disk, but are accessed only by a single application.

Any idea about the causes of this problem?
Thanks

[Michael Mattias]

The cause is what you suspected:
"It seems that sometimes the "close" statement isn't immediately executed by the operating system"

"Close" is a low-priority item for Windows.

MCM

[Mel Bishop]

And you progam has to flush any data it has in its buffers to the disk before it closes.

[Michael Mattias]

>And you[r] progam has to flush any data it has in its buffers to the disk before it closes

If you mean doing something (eg "FLUSH #hFile") in addition to executing the CLOSE statement, no, you don't. Windows will flush any cached data to disk automaticaly.

If you mean exiting the program without executing a CLOSE statement, then I don't know. I'd like to think Windows would flush the data under these conditions, too; but when you allow Windows to handle all this stuff you can never be certain.

MCM

[Claudio DalZovo]

Thanks!

Using "flush" before "close" may help to make faster the close operation?
That is, when the "flush" statement is executed, can we expect that program continue with the next statement (close) only when flushing is really done?

Opening the file on the local drive (when possible, giving the application logic) may also help to make faster closing it?
(by the operating system point of view, of course; it's sure that performance are better on local drive)

[Knuth Konrad]

I experienced a similar problem a while back when I created lots of temp. files for stress testing HW operations.

I used the following code to help speeding up the Windows caching time:

DECLARE FUNCTION FlushFileBuffers LIB "KERNEL32.DLL" ALIAS "FlushFileBuffers" (BYVAL hFile AS DWORD) AS LONG

Local hSysHandle, hMyHandle As Long

Open MyFile .... As hMyHandle

' Do stuff

Flush #hMyHandle
hSysHandle = FileAttr(hMyHandle, 2)
FlushFileBuffers hSysHandle
Close #hFile

[Michael Mattias]

That is, when the "flush" statement is executed, can we expect that program continue with the next statement (close) only when flushing is really done?

Nope. Statements are executed in order. When the first is done, the second is executed.

A CLOSE requires the buffer be flushed. If you FLUSH first, then close, then the close has no flushing to do.. but only because you already did it -and waited for it. The one difference "might" be that CLOSE without FLUSH puts the whole operation at the discretion of the operating system, whereas FLUSH will "do it now."

Opening the file on the local drive (when possible, giving the application logic) may also help to make faster closing

Yup. That, and reading and writing, too. And you are not subject to delays based on network traffic, either.

Seems to me your "loop and wait on Error 70" has met your application requirement. It ain't broke so don't fix it.

And - realistically - the speed of open/close is not going to be a big factor in your overall application execution time.

MCM

[Claudio DalZovo]

Nope. Statements are executed in order. The one difference "might" be that CLOSE without FLUSH puts the whole operation at the discretion of the operating system, whereas FLUSH will "do it now."

That's exactly the meaning of my question.

Both statements continue with next line when done (of course!), but while probably "close" requires some internal actions which the operating system may delay, we hope that "flush" force Win to an immediate action, thus leaving less work to do for "close".

Error 70 can still occurs, but (I hope) less frequently.
However I'll try to avoid repeated open/close of the same file, where possible

[Mike Doty]

Here is how I handle it within the the open file function since it
is unknown how fast the operating system will flush.

http://www.powerbasic.com/support/pbforums/showthread.php?t=24345