Announcement

Collapse
No announcement yet.

Random error 70 on repeated open/close

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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

  • #2
    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
    Michael Mattias
    Tal Systems Inc. (retired)
    Racine WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      And you progam has to flush any data it has in its buffers to the disk before it closes.
      There are no atheists in a fox hole or the morning of a math test.
      If my flag offends you, I'll help you pack.

      Comment


      • #4
        >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
        Michael Mattias
        Tal Systems Inc. (retired)
        Racine WI USA
        [email protected]
        http://www.talsystems.com

        Comment


        • #5
          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)

          Comment


          • #6
            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

            Comment


            • #7
              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
              Last edited by Michael Mattias; 28 Aug 2009, 08:29 AM.
              Michael Mattias
              Tal Systems Inc. (retired)
              Racine WI USA
              [email protected]
              http://www.talsystems.com

              Comment


              • #8
                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

                Comment


                • #9
                  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
                  How long is an idea? Write it down.

                  Comment

                  Working...
                  X