>We have a developer here who is using the command:
>
>COPY FILE (infile) TO (outfile)
>
>infile is fully qualified with a Novell drive letter e.g. K:\acmds\data\file.pdf
>
>outfile is a UNC to a NT server e.g. \\C402WebSrv\DocImg\01234.pdf
>
>When he runs his app he gets the VFP trapped error 1102:
>
>'Cannot Create File' but the file actually gets created on the NT.
>
>Has anyone seen this before.
>

SWAG, what's the user context for the target? This is NT Server as a target; is the user logged into an NT domain, a 2K AD, is authentcation for the server handled by NDS, or are they logged in locally to an account on the server, and if so, what UserID? I've been bitten more tha once where EdR\DOMAIN doesn't have the same rights as EdR\LocalSystem - usually I've assumed I've logged in as my Domain Admin account but thanks to not attaching to AD properly, end up logged in as a local user. If no explicit connection is being made to the NT server, you may be getting authenticated using the Windows userid and password by default, or may have a context inherited from a domain that isn't what you expect. One place I've seen this is where someone had Read and Write but not Modify permissions and they attempted an overwrite of an existing file.

I'd recommend explicitly connecting to the UNC either using Wscript.Network to log into the UNC using MapNetworkDrive to map the drive to a local letter with an explicit userid and password, or WNetAddConnection3() (see NETRESOURCE for a sample implementation; it can attach a UNC without mapping a drive, and like MapNetworkDrive it accepts a userid and password, and also permits you to specify a domain) and then use the Scripting.FileSystemObject or the Win32 CopyFile() API call to do the actual work if you're worried about VFP's COPY FILE (it doesn't do writing to ports well, for example). Not a lot more code IAC.