>It really surprised me to see 2 files with the same name--one CaseSum.pdf and the other casesum.pdf. I deleted one and it hasn't happened again.

In DOS 4.0 I saw uppercase duplicates...

>I couldn't get Rename to work: about half the time the "target" file never shows up. Perhaps I need some kind of loop to make sure the command completes before the next line executes? I have similar problems with Copy: about half of the time the destination file is corrupt. I suspect the source is being erased before the destination is complete. This is on a local machine so need to solve these here before I test on TS tomorrow :-)

The possible reason is that the code you run may be in a different thread, and it may return an OK before it's actually finished, or before the Windows actually close the file. Even with a single core processor that I have on this box, it used to happen a lot... which is why I wrote the WaitForFile method:

	PROCEDURE WaitForFile(tcFile)
		LOCAL lnUntil, lnPrevLen, lnCurLen, h, l, lnInterval
		DECLARE Sleep IN kernel32 INTEGER dwMilliseconds
*-- give it max 30 seconds into the future
		lnUntil=SECONDS()+30
		lnPrevLen=-2
		lnCurLen=-1
		lnInterval=500
*-- assume that whatever writes to a file will do so at least twice a second:
		DO WHILE lnPrevLen#lnCurLen AND SECONDS()<lnUntil
			Sleep(lnInterval)
			h=FOPEN(tcFile,10)
			IF h>0
*-- zero length doesn't count, still open by creator
				lnPrevLen=IIF(lnCurLen>0, lnCurLen, lnPrevLen)
				lnCurLen=FSEEK(h,0,2)
				FCLOSE(h)
				lnInterval=100	&& once it exists, check more often
			ENDIF
		ENDDO
		l=lnPrevLen=lnCurLen
		RETURN l

It should return .t. if the file length stayed the same non-zero length in two consecutive measurements. Not sure whether it's fullproof, some software may close the file at some point, then reopen it to add more, and this would then exit prematurely. Works for me, with Word.