I think Matt has put forward a very interesting point. Not being an web developer, I did a Google search and found this thread which talks about a similar approach. http://forums.asp.net/t/890935.aspx

It looks like these scanning software products cannot work with memory streams. You will have to save the stream to a disk file before running the scanning software. Which means your upload procedure might look like the following:

1. Save the incoming stream (the file to be uploaded) into a disk file

2. Run the scanning software

3. Wait for the scanning software to complete

4. (if there is no .NET interface, you might need to read the output file generated by the anti virus program to see the results)

5. If the file is clean, begin a transaction and open the FILESTREAM data file for write

6. Open the source file (the fiel you created at step 1) for read operation

7. read from the source file and write into the FILESTREAM data store.

8. close the files and commit the transaction.

Note that this approach involves writing two copies of the source file..first write it into a local file for scanning and then store it into the FILESTREAM data store.

This approach has more over head than a regular upload and more than double IO operations. However, it makes sure that the data getting into the FILESTREAM store is clan.

It is still not safe from some malicious software or human with sufficient permissions trying to overwrite the FILESTREAM data file with infected content. SQL Server does not lock the files in the FILESTREAM data store, unlike the MDF/LDF files. So a user or software with sufficient permissions can still replace the filestream data files or modify it. In such a case, when the data is served back to the client, it could be completely different from what is uploaded and could be an infected file as well (though the chances of something like that will be very very rare).