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

Peter Heinicke
Peter Heinicke used Ask the Experts™
Use A   && many records long

DO WHILE not eof()

      COPY NEXT 1 to bbb  && yes, it just keeps creating this one record file over and over


fails in when BBB is located on a network drive for some networks and works if BBB is located on the C drive. Why would that be? Could it be SMB1, 2 related?
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
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?
Amazon Web Services

Are you thinking about creating an Amazon Web Services account for your business? Not sure where to start? In this course you’ll get an overview of the history of AWS and take a tour of their user interface.


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.
    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.
      ? "Error copying file" + TRANSFORM(loEx.ErrorNo) + " " + loEx.Message && "Standard" error processing
      llLoopAllowed = .F.
  IF llCopyOK OR !llLoopAllowed
  WAIT WINDOW "Attempting to copy..." TIMEOUT 0.5

Open in new window

There is an option in the windows OS that when I changed it, caused this old school program to work on both the C drive and the network drive.

"Allow Caching of Share" should be unchecked, then the program worked. option to cache shares.
Yes, OS cannot release the file which is not synced between the cache and the shared volume. To use the cache is not a good practice. Off-line cache is the main reason of the file corruption.

And I wrote already: "This is purely OS issue" and "The copy function returns into the calling program even when the target file is not fully released."

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial