VVEngine Monitor Directory processes early

[Kyle]

We have VVEngine Monitoring a handful of directories for changes and copying files being created in them to final locations. We are having issues with the VVEngine Processing the change before the file is done being created and the copy failing due to file being open. The main problem is the global end script deleting the files in the directory. We couldn't get VV Variables working to just delete copied files so we ended just deleting all files in an end script. We most likely are going about things wrong so what we are trying to do is this. We have 7 copiers using old protocols. We have a low priority server to which all the copiers scan to. We then use VV to copy those files to the final locations on the more secure servers. After the copy is done we delete the file on the low priority server. I think this may not be a issue once move file is an option but for now we have an issue with files being open when copiers are creating semi larger files. Any advice or opinions?

[TGRMN Software]

In the VVEngine global settings there's an option to wait for X seconds of disk inactivity before kicking-off the profile... would that be useful? thanks
_________________
--
TGRMN Software Support
http://www.tgrmn.com
http://www.compareandmerge.com

[Kyle]

Just to add what we have figured out so far. Given this timeline - t1(start of document scan on copier) the copier creates a 0 byte file at the location. t2(VVengine picks up change in directory). t3(Profile starts). t4(Attempt to copy). t5(Global End Script runs-delete job). IF t4 and t5 failed due to file being open. T6(Copier completes file creation and new size is written. T7(VVEngine notes change in directory again). T8(profile starts again). T9(Copy job). T10(Global delete script).
Sorry for all the time slots but needed to explain. So VVEngine waits 3 secs of inactivity to run and waits no more then 59 now. Problem is the copiers can take up to 3 min to write the document and as far as we can tell there is no disk activity for most of that. We can't put the initial wait up to 50 as at max 59 it runs anyways. Now for the big files it's not a problem as both the copy AND delete fail due to file being open. There is a sweet spot of size where copy fails and delete works. That is what we need to figure out how to fix. Any ideas?

[TGRMN Software]

Is the delete script there to delete files after copy to simulate a move?
_________________
--
TGRMN Software Support
http://www.tgrmn.com
http://www.compareandmerge.com