*-- Not tested yet LOCAL ltNow, loEx AS Exception, llCopyOK, llLoopAllowed ltNow = DATETIME() llCopyOK = .F. llLoopAllowed = .F. DO WHILE .T. TRY COPY NEXT 1 to bbb llCopyOK = .T. CATCH TO loEx IF loEx.ErrorNo = 1705 AND DATETIME() - ltNow < 10 && Wait max 10 seconds and when access is denied llLoopAllowed = .T. ELSE ? "Error copying file" + TRANSFORM(loEx.ErrorNo) + " " + loEx.Message && "Standard" error processing llLoopAllowed = .F. ENDIF ENDTRY IF llCopyOK OR !llLoopAllowed EXIT ENDIF WAIT WINDOW "Attempting to copy..." TIMEOUT 0.5 ENDDO
Previous operating systems were less secure but faster and more reliable when accessing files over the network. Shared files access over the network is deprecated today. SMBx is just a part of this problem. Network access consists of many elements incl. 3rd party drivers etc. Everything tends to the client-server topology which is reliable enough... and which makes more money.
BTW, what error is reported and how often in your case?
You are not asking what to do and I have no direct answer but I have one theory:
You cannot ask Microsoft to fix VFP... Use Process Monitor and look what API calls are invoked by your COPY command. You may expect just a few file operations. Based on these calls create a short C++ code which does the same operations and which should fail the same way. Based on such failure Microsoft should start solving the problem because C++ is still supported language.