How to know when a file created is completed? (in FilestreamWatcher)
-
Hi, After reading Chris Maunder’s message, I am a little bit afraid of writing my message…. Anyway, I will make an effort to ask my message courteously. I used ‘FileSystemWatcher’ to read files from a directory path, what I had to do was to ReadAllBytes of the file had been created, to display the result in some way, and delete the file. I had a problem that had been discussed in many forums – how to know if the file’s create is completed, All brought to Microsoft forum: http://www.thescripts.com/forum/post1712613-10.html, I used the advice written there: while(true) { Try to open the file for reading Break if succeeded Catch an exception and sleep(1000) – if the file is in use by another process. } That worked as well. Now, my problem is when I send to the directory load of files at a short time – the FileStreamWatcher recognizes the first files – but stops there and doesn’t continue to read the all the others. I have no way to debug it line by line, because when I put a breakpoint there, passes enough time to read the next file… and the point is that the time between the create and delete is too short. Please pass the answer also to my direct email: sara.sekler@verint.com I hope my question is clear and brief enough …. :) Many thanks, Sarah
-
Hi, After reading Chris Maunder’s message, I am a little bit afraid of writing my message…. Anyway, I will make an effort to ask my message courteously. I used ‘FileSystemWatcher’ to read files from a directory path, what I had to do was to ReadAllBytes of the file had been created, to display the result in some way, and delete the file. I had a problem that had been discussed in many forums – how to know if the file’s create is completed, All brought to Microsoft forum: http://www.thescripts.com/forum/post1712613-10.html, I used the advice written there: while(true) { Try to open the file for reading Break if succeeded Catch an exception and sleep(1000) – if the file is in use by another process. } That worked as well. Now, my problem is when I send to the directory load of files at a short time – the FileStreamWatcher recognizes the first files – but stops there and doesn’t continue to read the all the others. I have no way to debug it line by line, because when I put a breakpoint there, passes enough time to read the next file… and the point is that the time between the create and delete is too short. Please pass the answer also to my direct email: sara.sekler@verint.com I hope my question is clear and brief enough …. :) Many thanks, Sarah
According to MSDN: The Windows operating system notifies your component of file changes in a buffer created by the FileSystemWatcher. If there are many changes in a short time, the buffer can overflow. This causes the component to lose track of changes in the directory, and it will only provide blanket notification. Increasing the size of the buffer with the InternalBufferSize property is expensive, as it comes from non-paged memory that cannot be swapped out to disk, so keep the buffer as small yet large enough to not miss any file change events. To avoid a buffer overflow, use the NotifyFilter and IncludeSubdirectories properties so you can filter out unwanted change notifications. To keep from missing events, follow these guidelines: Increasing the buffer size with the InternalBufferSize property can prevent missing file system change events. Avoid watching files with long file names. Consider renaming using shorter names. Keep your event handling code as short as possible.
#region signature my articles #endregion
-
According to MSDN: The Windows operating system notifies your component of file changes in a buffer created by the FileSystemWatcher. If there are many changes in a short time, the buffer can overflow. This causes the component to lose track of changes in the directory, and it will only provide blanket notification. Increasing the size of the buffer with the InternalBufferSize property is expensive, as it comes from non-paged memory that cannot be swapped out to disk, so keep the buffer as small yet large enough to not miss any file change events. To avoid a buffer overflow, use the NotifyFilter and IncludeSubdirectories properties so you can filter out unwanted change notifications. To keep from missing events, follow these guidelines: Increasing the buffer size with the InternalBufferSize property can prevent missing file system change events. Avoid watching files with long file names. Consider renaming using shorter names. Keep your event handling code as short as possible.
#region signature my articles #endregion
-
According to MSDN: The Windows operating system notifies your component of file changes in a buffer created by the FileSystemWatcher. If there are many changes in a short time, the buffer can overflow. This causes the component to lose track of changes in the directory, and it will only provide blanket notification. Increasing the size of the buffer with the InternalBufferSize property is expensive, as it comes from non-paged memory that cannot be swapped out to disk, so keep the buffer as small yet large enough to not miss any file change events. To avoid a buffer overflow, use the NotifyFilter and IncludeSubdirectories properties so you can filter out unwanted change notifications. To keep from missing events, follow these guidelines: Increasing the buffer size with the InternalBufferSize property can prevent missing file system change events. Avoid watching files with long file names. Consider renaming using shorter names. Keep your event handling code as short as possible.
#region signature my articles #endregion
-
with hope I've got what you meant - this is my problem: each file name is at least 25 characters, and the business I have to do inside is actually a bit of work... and it takes time.. Do you have any other idea? Thanks!! Sarah
If you have to do a lot of processing I suggest you use threads for that so that the event handler exits as soon as possible.
#region signature my articles #endregion