With w2K some caching problems are reported with IDE drives (ie: I use my disks with 'write cache enabled' = .F.)
Cetin

>Cetin,
>
>Thanks so much. It is still a source of confusion though, because I have already changed all the filename references with the word automation to include full paths, and it is still failing on the user's machine. And also, because it is failing in the instance where I am using run for the winzip, and in that case there is no word automation involved. I am not using the /N parameter. I still haven't replaced ALL the relative paths for the run command. I will do that next. It strikes me as odd that that could be a source of the problem, but I will try it anyway.
>
>I am still hoping (maybe vainly!) that the cause remains with the copies not being fully complete. Could it be that the OS thinks it is complete, but it is still writing buffers to disk or something similar, in the background?
>
>
>>David,
>>Unless you include /N (nowait) parameter VFP waits for run to finish. As well as it waits for 'copy file'.
>>What is the 'failure' ? MSWord is in question here I think. When passing filenames to word always use fullpathname IMHO.
>>Cetin
>>
>>>I am wondering about vfp's behaviour when executing the run command.
>>>
>>>A user just started using my new application. In all my testing on my machine(s) the following code executes fine:
>>>
>>>**hey don't worry about the macro substitution its an old habit!
>>>run winzip\wzzip &lctzipfile export_temp\*.*
>>>copy file (lctzipfile) to (lczipfile)
>>>
>>>also similar code such as:
>>>
>>>copy file (lcsourcefile) to (lctargetfile)
>>>odoc.open(lctargetfile)
>>>
>>>executes fine on my machine(s) (pentium 3 700/win98 and pentium2 450/win2000server)
>>>
>>>but the same code fails on my clients machine. (pentium 3 700/win2k professional)
>>>
>>>
>>>I am wondering whether control will return to vfp before the run command is finished executing, such that the file could still be in the middle of being written to at the time the next command executes?
>>>
>>>If so, is there a way to control the behaviour of the run command such that vfp waits until it is finished before executing the next line? Or are there alternatives to run that should be considered?
>>>
>>>In the case of the copy file command - does vfp just hand off control to an OS call, and possibly return before the command is completed?
>>>
>>>With regard to a possibly related subject, I believe (but I'm not sure) that in previous testing, using relative paths in the source and target files failed under win2k but succeeded using full paths, and worked using both relative paths and full paths under win98. But I can't imagine that win2k wouldn't understand a relative path! But maybe I am confused about this. Is it possible that the copy command takes a 'few milliseconds longer' with a full path than with a relative path, and therefore, if in fact the run returns before the copy is complete, I have a failure related to this problem, not the relative pathing?
>>>
>>>
>>>TIA