Why would this foxpro loop fail on a network drive, and work on a local drive

Yes, this is purely OS issue with a small contribution of the way how VFP uses API calls.

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.

Somebody said it might be a permissions issue. Where do I find out about process monitor?

If it would have been permission issue the it should fail immediately. Is it the case?

Process Monitor is available for download from Microsoft: https://docs.microsoft.com/en-us/sysinternals/downloads/procmon
Process Monitor should show the error number of the failed API call. What error reports FoxPro?

Access Denied (the same error you would get if someone else had opened the file)

Access denied could mean the OS did not finish the file copying. The copy function returns into the calling program even when the target file is not fully released. OS is attempting to speed the exclusive file access up this way. Certain antivirus programs could cause similar behavior.

I would expect the first copy when no target file exists can never fail.

Does the error appear when you are creating target files of the random names? (e.g. using SYS(2015) as the file name)

Dollars to donuts, it doesn't appear on sys2015. How could I mitigate this behavior?

What behavior would you like to mitigate? The SYS(2015) behavior or are you really looking for a way how to copy the same row into the same file again and again?

The behavior where foxpro code fails because the copy function returns before the OS is finished with the file. I think I am seeing this in production code.
1.) I would like to verify that this is the problem and
2.) I would like to eliminate it. Sometimes tweaking buffer settings and registry settings has accomplished this in the past with similar situations.

The code that produces the error has been stable, but the error has been happening a lot since 9/25 and we can't correlate it to OS changes so far.

The check for file copy success can be done in the TRY - CATCH block for e.g. 10 seconds with immediate exit when error different from 1705 occurs:

*-- 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

Select allOpen in new window