Announcement

Collapse
No announcement yet.

Random error 70 on repeated open/close

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
    Mike Doty
    Member

  • Mike Doty
    replied
    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/pb...ad.php?t=24345

    Leave a comment:

  • Claudio DalZovo
    Member

  • Claudio DalZovo
    replied
    Originally posted by Michael Mattias View Post
    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

    Leave a comment:

  • Michael Mattias
    Member

  • Michael Mattias
    replied
    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
    Michael Mattias
    Member
    Last edited by Michael Mattias; 28 Aug 2009, 08:29 AM.

    Leave a comment:

  • Knuth Konrad
    Member

  • Knuth Konrad
    replied
    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:

    Code:
    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

    Leave a comment:

  • Claudio DalZovo
    Member

  • Claudio DalZovo
    replied
    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)

    Leave a comment:

  • Michael Mattias
    Member

  • Michael Mattias
    replied
    >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

    Leave a comment:

  • Mel Bishop
    Member

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

    Leave a comment:

  • Michael Mattias
    Member

  • Michael Mattias
    replied
    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

    Leave a comment:

  • Claudio DalZovo
    Member

  • Claudio DalZovo
    started a topic Random error 70 on repeated open/close

    Random error 70 on repeated open/close

    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
Working...
X