我有一个应用程序，我正在寻找一个文本文件，如果对文件做了任何更改，我使用OnChanged事件处理程序来处理事件。我正在使用NotifyFilters。LastWriteTime，但是事件仍然被触发两次。这是代码。
public void Initialize()
{
FileSystemWatcher _fileWatcher = new FileSystemWatcher();
_fileWatcher.Path = "C:\\Folder";
_fileWatcher.NotifyFilter = NotifyFilters.LastWrite;
_fileWatcher.Filter = "Version.txt";
_fileWatcher.Changed += new FileSystemEventHandler(OnChanged);
_fileWatcher.EnableRaisingEvents = true;
}
private void OnChanged(object source, FileSystemEventArgs e)
{
.......
}
在我的情况下，OnChanged被调用两次，当我改变文本文件version.txt并保存它。
解决方案实际上取决于用例。您是否在注意不更改的新文件，或每隔一段时间更改一次的文件或经常更改的文件?在我的情况下，它的变化不太频繁，我不想错过任何这些变化。
但是我也不想在写入过程尚未完成写入的地方发生更改事件。
在我的情况下，我注意到6 (6 !!)onchange事件写一个125字符的txt文件。
我的解决方案是民意调查和改变事件的混合，民意调查经常被消极地看待。正常轮询比较慢，比如每10秒一次，以防FileSystemWatcher (FSW)“错过”一个事件。轮询立即响应FSW更改事件。
关键是在FSW。更改事件时，轮询速度加快，例如每100毫秒，并等待直到文件稳定。因此我们有了“两阶段轮询”:阶段1比较慢，但在FSW文件更改事件时立即响应。第二阶段是快速的，等待一个稳定的文件。
如果FSW检测到多个文件更改，每个事件都会加速轮询循环，并有效地启动一个新的短等待周期。只有在轮询循环检测到上次写入时文件没有进一步的变化之后，它才假定文件是稳定的，并且您的代码可以处理更改后的文件。
我选择了10秒和100毫秒的超时，但是您的用例可能需要不同的超时值。
这里是轮询，其中AppConfig。fiIO是要注意的FileInfo:
private readonly EventWaitHandle ewhTimeout = new AutoResetEvent(false);
private void TwoPhasedPolling()
{
bool WaitForChange = true; //false: wait until stable
DateTime LastWriteTime = DateTime.MinValue;
while (true)
{
// wait for next poll (timeout), or FSW event
bool GotOne = ewhTimeout.WaitOne(WaitForChange ? 10 * 1000 : 100);
if (GotOne)
{
// WaitOne interrupted: end of Phase1: FSW detected file change
WaitForChange = false;
}
else
{
// WaitOne timed out: Phase2: check file write time for change
if (AppConfig.fiIO.LastWriteTime > LastWriteTime)
{
LastWriteTime = AppConfig.fiIO.LastWriteTime;
}
else
{
// End of Phase2: file has changed and is stable
WaitForChange = true;
// action on changed file
... your code here ...
}}}}
private void fileSystemWatcher1_Changed(object sender, FileSystemEventArgs e)
{
ewhTimeout.Set();
}
NB:是的，我也不喜欢}}}}，但它使列表更短，这样你就不必滚动了:-)
我简单地添加了一个dupe检查如下:
private void OnChanged(object source, FileSystemEventArgs e)
{
string sTabName = Path.GetFileNameWithoutExtension(e.Name);
string sLastLine = ReadLastLine(e.FullPath);
if(sLastLine != _dupeCheck)
{
TabPage tp = tcLogs.TabPages[sTabName];
TextBox tbLog = (TextBox)tp.Controls[0] as TextBox;
tbLog.Invoke(new Action(() => tbLog.AppendText(sLastLine + Environment.NewLine)));
tbLog.Invoke(new Action(() => tbLog.SelectionStart = tbLog.Text.Length));
tbLog.Invoke(new Action(() => tbLog.ScrollToCaret()));
_dupeCheck = sLastLine;
}
}
public static String ReadLastLine(string path)
{
return ReadLastLine(path, Encoding.Default, "\n");
}
public static String ReadLastLine(string path, Encoding encoding, string newline)
{
int charsize = encoding.GetByteCount("\n");
byte[] buffer = encoding.GetBytes(newline);
using (FileStream stream = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.ReadWrite))
{
long endpos = stream.Length / charsize;
for (long pos = charsize; pos < endpos; pos += charsize)
{
stream.Seek(-pos, SeekOrigin.End);
stream.Read(buffer, 0, buffer.Length);
if (encoding.GetString(buffer) == newline)
{
buffer = new byte[stream.Length - stream.Position];
stream.Read(buffer, 0, buffer.Length);
return encoding.GetString(buffer);
}
}
}
return null;
}
[DllImport("user32.dll", CharSet = CharSet.Auto)]
private static extern int SendMessage(IntPtr hWnd, int wMsg, IntPtr wParam, IntPtr lParam);
private const int WM_VSCROLL = 0x115;
private const int SB_BOTTOM = 7;
/// <summary>
/// Scrolls the vertical scroll bar of a multi-line text box to the bottom.
/// </summary>
/// <param name="tb">The text box to scroll</param>
public static void ScrollToBottom(TextBox tb)
{
SendMessage(tb.Handle, WM_VSCROLL, (IntPtr)SB_BOTTOM, IntPtr.Zero);
}
解决方案实际上取决于用例。您是否在注意不更改的新文件，或每隔一段时间更改一次的文件或经常更改的文件?在我的情况下，它的变化不太频繁，我不想错过任何这些变化。
但是我也不想在写入过程尚未完成写入的地方发生更改事件。
在我的情况下，我注意到6 (6 !!)onchange事件写一个125字符的txt文件。
我的解决方案是民意调查和改变事件的混合，民意调查经常被消极地看待。正常轮询比较慢，比如每10秒一次，以防FileSystemWatcher (FSW)“错过”一个事件。轮询立即响应FSW更改事件。
关键是在FSW。更改事件时，轮询速度加快，例如每100毫秒，并等待直到文件稳定。因此我们有了“两阶段轮询”:阶段1比较慢，但在FSW文件更改事件时立即响应。第二阶段是快速的，等待一个稳定的文件。
如果FSW检测到多个文件更改，每个事件都会加速轮询循环，并有效地启动一个新的短等待周期。只有在轮询循环检测到上次写入时文件没有进一步的变化之后，它才假定文件是稳定的，并且您的代码可以处理更改后的文件。
我选择了10秒和100毫秒的超时，但是您的用例可能需要不同的超时值。
这里是轮询，其中AppConfig。fiIO是要注意的FileInfo:
private readonly EventWaitHandle ewhTimeout = new AutoResetEvent(false);
private void TwoPhasedPolling()
{
bool WaitForChange = true; //false: wait until stable
DateTime LastWriteTime = DateTime.MinValue;
while (true)
{
// wait for next poll (timeout), or FSW event
bool GotOne = ewhTimeout.WaitOne(WaitForChange ? 10 * 1000 : 100);
if (GotOne)
{
// WaitOne interrupted: end of Phase1: FSW detected file change
WaitForChange = false;
}
else
{
// WaitOne timed out: Phase2: check file write time for change
if (AppConfig.fiIO.LastWriteTime > LastWriteTime)
{
LastWriteTime = AppConfig.fiIO.LastWriteTime;
}
else
{
// End of Phase2: file has changed and is stable
WaitForChange = true;
// action on changed file
... your code here ...
}}}}
private void fileSystemWatcher1_Changed(object sender, FileSystemEventArgs e)
{
ewhTimeout.Set();
}
NB:是的，我也不喜欢}}}}，但它使列表更短，这样你就不必滚动了:-)
以下是我的方法:
// Consider having a List<String> named _changedFiles
private void OnChanged(object source, FileSystemEventArgs e)
{
lock (_changedFiles)
{
if (_changedFiles.Contains(e.FullPath))
{
return;
}
_changedFiles.Add(e.FullPath);
}
// do your stuff
System.Timers.Timer timer = new Timer(1000) { AutoReset = false };
timer.Elapsed += (timerElapsedSender, timerElapsedArgs) =>
{
lock (_changedFiles)
{
_changedFiles.Remove(e.FullPath);
}
};
timer.Start();
}
这是我在一个项目中用来解决这个问题的解决方案，在该项目中，我将文件作为附件发送到邮件中。
它可以很容易地避免两次触发事件，即使是一个较小的定时器间隔，但在我的情况下，1000是可以的，因为我更喜欢错过一些变化，而不是每秒用> 1条消息淹没邮箱。
至少在同时更改多个文件的情况下，它可以正常工作。
Another solution I've thought of would be to replace the list with a dictionary mapping files to their respective MD5, so you wouldn't have to choose an arbitrary interval since you wouldn't have to delete the entry but update its value, and cancel your stuff if it hasn't changed.
It has the downside of having a Dictionary growing in memory as files are monitored and eating more and more memory, but I've read somewhere that the amount of files monitored depends on the FSW's internal buffer, so maybe not that critical.
Dunno how MD5 computing time would affect your code's performances either, careful =\
