I monitor files that are dropped on a ftp via filesystem watcher then move to another dir. Now I trigger the copy off the create event of the filesystem watcher but obviously in the case of ftp the create is just a stub file and the data comes in and fills the file as it uploads till complete. Anyone have an elegant solution for this, or do I have to do what I think I have to do
1 wait till last access time is about n ms in past before I copy
2 throw a control file in there to state that that file is done being copied, then delete control file
3 pound the crap out of it
Have the source upload a stub file directly after the data file completes, and have your FileSystemWatcher watch for the stub file. For example, if the data file name is mydata_01234 then the stub woulb be mydata_01234_stub. The FileSystemWatcher should then have a mask of "*_stub". You then know the data file name by stripping off the "_stub" suffix. And the stub file cannot be uploaded until after the data file completes, so the data file will be free.
If the stub files are just one byte each you should be able to remove them after whatever operation you're performing with the data file without issue. If your operations are particularly fast, add a 100 ms sleep before deleting the stub.
Wait until you can exclusively open the file- I wouldn't go as far to say that it is a nice solution, but probably the safest strategy in the circumstances.
When file gets copied from another server using FTP, before complete file copy , file name gets renamed with extra extension like .TMP as shown in path example below.
C:\InterfaceServer\OilAndGas\XMLForTest\TestStbFile.xml.TMP
To overcome this situation follow two steps
You need to just call the below method to remove the extra extension and add wait for 2 seconds in the code so that the complete file gets created and you can use it for further processing.
this is a very naive implementation but it suits my purposes, i have seen enough people with this problem on the web so decided to contribute. The implementation is fairly specific to my needs I almost completely unconcerned with changed events given the nature of my problem but people can throw their own code in there if they need to do something different, it really the created which cause the most issues. I havent fully tested this but at first write it looks good
here's an implementation to keep in sync
4 years later....
the stub file is a good idea, but, probably a slightly more robust way to do it is to have your source create a stub file first, upload your "real" file, then delete the stub.