Announcement

Collapse
No announcement yet.

Error 58 File Already Exists

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

  • Error 58 File Already Exists

    Please add your comments and suggestions as a Reply to this thread.





    PB/WIN - Error 58 - File already exists
    File already exists - (%ERR_FILEALREADYEXISTS) - The new name argument specified in your NAME statement already exists.

    Last edited by Gary Beene; 28 Oct 2014, 11:22 PM.

  • #2
    Error 58 besides Name command

    Is there any other way to generate this error besides the NAME command?

    I get this error at random times. Could go for weeks or months and then it pops up. In my code I always test for the existence and KILL the destination file in the line preceding the NAME command. Unless another user can create the destination file on a network in between those two line I am at a loss.

    KILL File2$
    NAME File1$ AS File2$ 'Can still get ERR 58 here

    Frank

    Comment


    • #3
      We've seen this report here before. While KILL (actually the underlying system call) is a 'low priority' operation subject to being deferred, the cacheing mechanism is supposed to handle that. "Hey, here's a rename, you'll have to do that deferred delete first."

      Maybe you could try something like
      Code:
        WHILE ISFILE ( filename2) 
           KILL FileName2                     
           NAME fileName as filename2 
        WEND
      Maybe add a "tries" counter using ON ERROR or TRY.. CATCH, and give up after "too many."

      With regard to "another user" re-creating the (KILLed) file between execution of your two statements, the answer is, "yes, that is possible albeit unlikely."

      I can't remember the last time I actually used a KILL/NAME sequence (I just don't do that) so others may have better workarounds.

      Comment


      • #4
        Thank You Michael,

        Your code is almost exactly what I currently use.

        After I posted the question, the only thing I could come up with is what your suggesting, changing my error handling routine to try it twice. If you get a 58 retry the delete and rename. I was just wondering if I missed something else.

        Frank

        Comment


        • #5
          Frank
          Does your problem happen only when the file is on a shared device.
          Also a warning. On a Linux shared device. You can delete a file currently in use.
          The one using the file will continue to use the deleted file until the one closes the file.

          Might it be better is you opened the file in non shared mode first and if that is successful then Kill the file.
          p purvis

          Comment


          • #6
            Hi Paul,

            Yes, the file is on a shared device. Windows 2003 Small Business Server.

            If the file is open you cannot kill it even if it is you that has it open. When it is closed by everyone on the network then you can kill it.

            Comment


            • #7
              If you allow files to be cached on a client.
              You might want to be view this as far as multi user access.

              http://technet.microsoft.com/en-us/l...00(WS.10).aspx
              p purvis

              Comment


              • #8
                Maybe put a SLEEP X just after the KILL statement to let the program catch up with itself?
                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


                • #9
                  Thanks Paul and Mel. I'll do some reading and maybe try the SLEEP command. It happens so infrequently is why I asked if something else could be going on. Since I originally posted, I wrote a program that makes a file, deletes the original and then renames in a loop. It did the rename 20K times before I turned it off. It never had a error.

                  Code:
                  #COMPILE EXE
                  #DIM ALL
                  
                  'Testing NAME command after delete. Delete is a low priority and could be delayed after NAME.
                  
                  FUNCTION PBMAIN () AS LONG
                    LOCAL FileName1 AS STRING, FileName2 AS STRING, Counter AS LONG
                  
                    ON ERROR GOTO DispError:
                  
                    FileName1="FileName1.txt"
                    FileName2="FileName2.txt"
                  
                    IF ISFILE(FileName1) THEN KILL FileName1
                    IF ISFILE(FileName2) THEN KILL FileName2
                  
                    OPEN FileName1 FOR OUTPUT AS #1
                      WRITE #1,"Hello"
                    CLOSE #1
                  
                    DO
                  1:    OPEN FileName2 FOR OUTPUT AS #2
                  2:      WRITE #2,"Hello"
                  3:    CLOSE #2
                  
                  4:    IF ISFILE(FileName1) THEN KILL FileName1
                  5:    NAME FileName2 AS FileName1
                  
                  6:    INCR Counter
                  7:    LOCATE 1,1: PRINT Counter
                  
                  8:    IF LEN(INKEY$)>0 THEN EXIT LOOP
                    LOOP
                  
                    EXIT FUNCTION
                  
                  DispError:
                    PRINT ERR, ERL
                    WAITKEY$
                    END
                  END FUNCTION

                  Comment


                  • #10
                    Frank I wrote similar code and ran it while watching a server's open files.
                    If others can open the same file on a server, you are very likey to br running into network file cache from another workstation.
                    I have seen problems silmilar come from trying to run batch backup routines zipping files on a backup workstation of a server when another workstation had the files to be backed up open less than 10 seconds ago.
                    When dealing with workstations and servers. Your going to be dealing with more than likely open files due from SMB file cache. The only way to circumvent the issue is by disabling it on the client, the server, on nix servers using veto oplocks, shorting the time a file's cache in time can be usually in the registry.
                    I have not found a way to remove the open file cache timeout. It is a system wide operation the was not designed for application manipulation. I have observed the KILL statement does have the effect of removing the condition.

                    The only way I might expect you can get around the problem of issues where having more than one workstation access a file and the server keeps the file open for a short brief of time due to Microsofts SMB performance protocols.
                    Is to try to open a file in some exclusive mode and using that as a test for who full control over a file before any file deleting, renaming, etc operations. I have not tried Method yet. Exempt that I do this now in a batch routine on a backup client workstation at the beginning of the routine to confirm no files are open on server that this backup process will be using.

                    If the file's are local to the machine and there is zero chance of multiple user/instance use of the file. I do not think you will see the problems we are discussing.
                    Last edited by Paul Purvis; 21 Nov 2014, 12:45 PM.
                    p purvis

                    Comment


                    • #11
                      This code should help on renaming files


                      Code:
                      FUNCTION Killfile100(BYREF filename AS STRING, BYREF seconds AS LONG) AS LONG
                      LOCAL ierr AS LONG
                      LOCAL icount AS LONG
                      LOCAL itimerstart AS LONG
                      LOCAL itimerend AS LONG
                      LOCAL ikillfile100id AS LONG
                      
                        itimerstart=TIMER
                        ikillfile100id=FREEFILE
                        IF seconds<0& THEN seconds=0&
                        icount=1
                      
                        WHILE icount
                           INCR icount
                           ERRCLEAR
                           OPEN filename FOR INPUT  AS #ikillfile100id
                           ierr=ERR
                           CLOSE #ikillfile100id
                           IF ierr=53& THEN EXIT
                           KILL filename
                           IF icount=19 THEN
                               itimerend=TIMER
                               IF itimerend<itimerstart THEN itimerend+=86400
                               SLEEP 16:icount=1
                               IF itimerend-itimerstart-1>seconds THEN icount=0
                          END IF
                        WEND
                      
                        IF ierr=53& THEN
                           FUNCTION=1
                           ELSE
                           FUNCTION=0
                        END IF
                      END FUNCTION
                      Code:
                      IF KILLfile100(sfilename2,15) THEN
                          ERRCLEAR
                          NAME sfilename1 AS sfilename2
                          ierr=ERR
                          IF ierr THEN 
                              STDOUT  "do something"
                           END IF
                      ELSE 
                          STDOUT "cannot rename the file name , the destination file name already exist"
                      
                      END IF
                      p purvis

                      Comment


                      • #12
                        If the problem occurs only in a network or other 'shared' environment, maybe you need to think about re-engineering the network-enabled version of your application?

                        I know I'd never even think about using KILL/NAME if the file could be opened by another user, or even if that other user could himself perform a KILL/NAME.

                        Comment


                        • #13
                          After reading a lot about OPLOCKS and files being cached on the local client and with an environment of multiple workstations accessing the same directories and files on a server. I think for stability sakes. These registry edits may be best practice on all workstations. I have no practical experience or test with making these changes. I would think that this may have a positive effect in a networking environment where files are shared.
                          If a workstation does not share file directories, these changes should not have any effect.
                          please see
                          http://technet.microsoft.com/en-us/l...=ws.10%29.aspx

                          Code:
                          Windows Registry Editor Version 5.00
                          
                          [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters]
                          "FileInfoCacheLifetime"=dword:00000000
                          "FileNotFoundCacheLifetime"=dword:00000000
                          "DirectoryCacheLifetime"=dword:00000000
                          p purvis

                          Comment


                          • #14
                            I came across this webpage today doing other research on cache in the redirector in file sharing.
                            This might be the problem or not.
                            https://support.microsoft.com/en-us/...-is-deleted-in
                            SMB2 directory cache is not updated correctly if a file is deleted in Windows 7 or in Windows Server 2008 R2


                            p purvis

                            Comment


                            • #15
                              also another page.
                              https://docs.microsoft.com/en-us/pre...686200(v=ws.10)

                              Here is another default client default changes I make my systems where data files are shared.
                              On most servers systems, we are running SMB1 where I can disable(turn off) "opportunistic file locking" on the client computers.
                              If you want to have high performance on file server accessing lots of files or large directories, then these setting might have a negative effect on performance.
                              Data file stability is more important to me for my purposes.
                              Code:
                              Windows Registry Editor Version 5.00
                              
                              [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters]
                              "ScavengerTimeLimit"=dword:00000002
                              "EnableSecuritySignature"=dword:00000000
                              "RequireSecuritySignature"=dword:00000000
                              "DisableBandwidthThrottling"=dword:00000001
                              "FileInfoCacheLifetime"=dword:00000000
                              "FileNotFoundCacheLifetime"=dword:00000000
                              "DirectoryCacheLifetime"=dword:00000000
                              "DisableByteRangeLockingOnReadOnlyFiles"=dword:00000001
                              "CacheFileTimeout"=dword:00000003
                              "DormantFileLimit"=dword:0000003
                              ScavengerTimeLimit is only effect in windows XP.
                              On one client computer, I do not disable "opportunistic file locking" because there is a daily routine that will take 20 minutes due to poor network programming by our vendor programmer, if i have it disabled. That is due from sorting a file on the server with small blocks of records which should be done in memory or on a local drive.
                              Security of traffic to SMB servers is not of an issue, due to no computers in the network can see the traffic that have possible viruses.
                              p purvis

                              Comment

                              Working...
                              X