>>>>>>>>>Have a VFP Application which does a File Copy from a mapped Drive. Works fine in XP, Win7 & Win8.
>>>>>>>>>
>>>>>>>>>In Windows 10 am getting a File Not Found Error even though the Mapped Drive and File are visible in Windows Explorer.
>>>>>>>>
>>>>>>>>If you run the app in Windows 7 compatibility mode (but make no other changes) do you still get the error?
>>>>>>>
>>>>>>>Yes
>>>>>>
>>>>>>On the Wndows 10 machine, can you read/write files from the windows explorer in that mapped drive and folder ?? It sounds like a permissions problem to me.
>>>>>
>>>>>Yes can do a File Copy directly in Windows Explorer. The FoxPro App doesn't see the Network Folder.
>>>>>
>>>>>Also - this is a Laptop running a Wireless connection
>>>>
>>>>Is the Foxpro app trying to do a read, or write, or copy, or delete? Or some combination of these???
>>>
>>>Trying to do a Copy. CD to the Mapped Drive doesn't work either - think this is a Windows 10 Bug (or as Microsoft likes to say not a Bug but a Feature).
>>
>>When I've had this exact same problem it was a permissions issue. From the Windows 10 machine... open explorer window, right click on the folder you can't copy too , from popup menu select properties, then in popup window select the 'security' tab. From there you should be able to see the permissions you have for that folder. Remember, if you're on a domain the domain account you're using needs to have the permissions. Once you make changes there, close the window and then go back into it to make sure the changes you made are still there.
>
>Am running a program that copies and registers files from a Subfolder on a mapped Drive. Can manually copy via Windows Explorer. Permissions look OK. Even a CD line doesn't recognize the Mapped Drive as a Letter.

What OS is the host system (i.e. the system that is hosting the directory to which you're creating a drive map).
Are we doing this within a domain context? If not on a domain but on a peer-to-peer mode, then due to some peculiarities in the authentication mechanism involved, I've noticed that you sometimes have to use fully-qualified name (e.g. might have to explicitly specify user as "hostname\username" to authenticate properly at the host, as I've seen occasions where only specifying name causes attempt to authenticate with "workstation\username" which is not likely to work -- especially if at some point had performed authentication with a different username during the session)