File Move in Foxpro

[PatMcLaughlin]

We have a process that works like a 'Traffic Cop' processing thousands of files daily. It works when a user copies a .txt file to a specific file folder, the process will see it, open it, process it, then it copies it to a 'done' folder and deletes the original file. (A "Move") Recently, we are experiencing the problem that the program will send the command to delete the file before it is completed with the copy. (File access denied). We cannot find a MoveFile() in VFP so we are contemplating using the Rename command. It is critical not to break this system if at all possible. Are we on the right track? Is there a sync/async we have overlooked?

 

[Mike Lewis]

The RENAME command is, in effect, the same as a MOVE command. If you rename a file, and give it a different path, the system will move the file to that path, which is what you want.

So you shouldn't need to delete the file after you rename it. But, to be safe, it would be a good idea to pause the program for, say, 500 ms, after each move - although with thousands of files to process each day, that might slow down the app to an unacceptable extent.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[PatMcLaughlin]

Hi Mike,
In testing, it works great until you hit a file that has the same name, which happens often as they submit files from an AS400 with a name such as AFORM001 - AFORM002 etc. Once it reaches AFORM999 it starts over. When the 'Rename' is used, it comes back announcing that the file already exists. Since it is a standalone system, it will stop the process until you manually delete the old and move the new. Copy file did not do that, it just overwrote the file.

 

[Olaf Doschke]

If you do COPY FILE, the next line should only execute after the copy has been made, but since some other file related commands like PACK or ALTER TABLE are also reported to fail from time to time, due to too early access to a file or too late, the OS or anything else might interfere.

How are you reacting to new files? Do you do ADIR in a timer? Did you use WMI and subscribe to folder events? If you do anything, which might run in parallel to code copying and deleting files you may step on your own feet. I would suggest doing an intermediate copy to a single defined file name which also causes a wait condition for the next file.

1. When finding a new file, check if .\processing\current.txt exists and if so, wait for it to disappear
2. When .\processing\current.txt disappeared remember the original file name and RENAME the file to .\processing\current.txt to process it.
3. When finished processing RENAME .\processing\current.txt to .\done\ORIGINALNAME as remembered in step 2.

Bye, Olaf.

 

[JRB-Bldr]

When I had questions about the COPY being completed prior to the ERASE, (as Olaf mentions above) I used the ADIR() function to compare the two file sizes (source & destination).

Until the two text file sizes were the same, I would go into a Loop waiting for the COPY to complete.
Once the two text file sizes were the same it was safe to delete the source file (or at least safer than without the size compare).

As to: until you hit a file that has the same name

My file copy routines always check the Destination directory before initiating a COPY.

If a file of the same name should exist in the Destination directory I would typically append a number (<filename>-2.txt, <filename>-3.txt, etc.) to the new destination file so as to differentiate it from the other file - rather than merely over-writing the file.

Again the ADIR() function can be used to count Destination files of the same name.

Then, if necessary, an individual can see both files and through the Windows Explorer can see the individual file's Date & Time.

Good Luck,
JRB-Bldr

 

[Mike Lewis]

Another thing you could do is to wrap the command in a TRY/ENDTRY block. That will trap any error that the command throws (such as "file already exists") and that would give you a chance to take some special action for that one file. If nothing else, you would be able to deal with the problem without holding up the processing of all the remaining files.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads