You can use several non-VFP helpers to achieve that with less effort.
1. Scan folder: ADIR is there for that. Also SYS(2000)
2. Hourly run: To run something regularly Windows offers Scheduled Tasks. This includes the facility to inform about good and bad runs via exit code (eg monitoring a network folder might not work if network has an outage, which of course means you ideally do this at the computer or server where the folder is on a local drive, VFP runs on server OSes, too, so no problem here)
3. Email about it: There are tons of ways to send a mail and the big advantage over sending a mail from a scheduled task is you can set the text body to anything, TEXT TO text merging here is helpful in using texts with placeholders.
4. Renaming the file and moving it: This is one thing with RENAME, as Mike said. If the target folder is on the same physical drive or you can manage this to go there, using Windows API function MoveFile or MoveFileEx would be a good idea as these API functions move files very fast, even large files. They don't really move much on HDD, they only modify their table of content entry, like changing which folder the file belongs to with file metadata not part of the file itself. Only possible when the file stays on the same partition, though. Every file in the file system has TOC information and I'm not talking of file attributes but the main core information about a file not part of it.
So assume these files are CSV data coming from a third party, you process them and put them away for backup storage, it wouldn't matter if it's 100MN or GB sized files, they move to the target folder in the blink of an eye with MoveFileEx. Been there, done that.
So overall What actually remains from your task as the VFP executable portion is the code necessary to do bullet points 1,3, and 4.
There's one more thing you could use: WMI, that allows monitoring folders, see
[URL unfurl="true"]https://devblogs.microsoft.com/scripting/use-powershell-to-monitor-for-the-creation-of-new-files/[/url]. You can do very many things in Powershell scripts more than just displaying the name of a new file, so you could also do the whole task with Powershell and WMI event monitoring as is used there.
And to add to that, the target folder may also be one that's connected up to cloud drive space like Dropbox, Google Drive, One Drive, etc. So your executable has nothing to do about backing up processed files as archives source of data reference other than putting processed files into that target folder.
As you should install that on a server where an "inbox" folder typically is situated, the only concern about using VFP for an executable doing the job instead of anything lower level like a Powershell script is what I experienced more than once: The server admins are not in touch with departments putting up such mechanism on the server and even though the company knows you're the vendor of this (or you're even from the department needing this feature itself), this comes up as failing or even missing after a server is replaced or moves. And something based on Powershell then can have a higher chance of survival.
Though I wouldn't bash on admins too much. It's just important to have an IT/DevOps department, which cares for more than the main SQL Server or Web server running on the in-house servers and a VFP app can simply be copied over as this task has no 3rd party dependency (if you don't pick a mail option needing some registered ActiveX component). You can put the VFP runtimes into the folder of your EXE and it runs without a setup to be reapplied on a new or moved or virtualized server.
Just be warned, such things are not seldom put up in a shoot and forget fashion and it's hard to keep dedication about things like this even if you establish a wiki or other means of reference documentation.
Bye, Olaf.
Olaf Doschke Software Engineering
