Summary
The File Trigger can be used to trigger adTempus jobs based on the creation, modification, or deletion of files. The File Trigger can monitor "remote" files (files on a computer other than the one where the adTempus service is running), but the trigger must be configured using UNC paths, and may produce incorrect results if the network connection is broken.
More Information
UNC Paths
File Triggers are evaluated in the context of the user whose account the job runs under. Therefore, that user must have access to the network resource you are monitoring.
However, network resources defined on the Resources page for the job are not loaded until the job begins execution, after triggers have been satisfied. Therefore your File Trigger cannot use network drives mapped on the Resources page, or any other network resources that require credentials other than the primary credentials for the job. That is, if the files you want to monitor are "h:\myfiles\*.txt" and the H: drive is mapped to \\server1\share1, you must use "\\server1\share1\myfiles\*.txt" in your File Trigger. If you use a mapped drive letter, the trigger will never find any files.
Incorrect Results
The File Trigger works by scanning the target directories at intervals of 10 to 30 seconds and comparing the list of files it finds with the list of files it found on the previous scan. Based on this comparison it determines whether a file is new (not present in previous scan), modified (changed from previous scan), or deleted (present in previous scan, not present in current scan).
When the File Trigger is used to monitor files over a network connection, a problem occurs when the network connection is broken. When this happens, adTempus does not detect that the network connection is broken, but simply finds no files when it performs its scan. This makes it think that all files it found in the target directory during the last scan have now been deleted. If the job is configured to trigger on file deletion, it is now triggered. When the connection is subsequently re-established, adTempus finds the files again, but since they were not present on the previous pass, it believes that they have been newly created, and therefore triggers the job if the job is configured to trigger on job creation.
Workaround
To avoid this limitation if you are triggering based on file creation, always remove the trigger file or move it to another (non-monitored) directory as part of your job processing. This will prevent adTempus from re-triggering for this file if the connection is broken and re-established.
