这不是关于代码的问题,而是FileSystemWatcher / OS行为。我有一个应用程序,它监视日志文件的thousends。该应用程序 多年来一直没有任何问题。它在Server 2003上针对Server 2003上托管的共享运行。
如果它在Server 2008(R2)上运行且存储在Server 2008(R2)上,则不会生成太多事件。我做了一个简单的repro,显示了差异[但正如我所说:长期运行的旧程序确实正常工作]。生成日志的应用程序不受我的代码控制。 在我的repro中 - 写入这样的日志暂停 - 即使是作者和/或底层流的刷新也没有用。]
在Server 2003上,每次更新[来自日志记录应用程序的写入操作]都会导致FSW触发Size更改的事件。在Server 2008上,仅当应用程序开始写入日志文件以及日志文件关闭时才会发生这种情况。中间没有任何事件。设置REG键以写入NTFS时间戳不会对此行为进行任何更改。
我无法在MS打开电话,但可能有人看到了这种行为并知道解决方法。
我想到的解决方法是:降级到Server 2003或Linux。两者都按预期工作。
任何想法都非常受欢迎。
致以最诚挚的问候,
++ mabra
[Net 2.0 => 4.0;毫无疑问:所有补丁,操作系统也是]
[编辑]
抱歉,我的分析中存在缺陷....随着我的移动 应用程序到Server 2008,一个新的应用程序来到要监视的文件集[更改 从来没有两件事同时......]。新的应用程序有另一种行为, 然后是我之前读过的日志应用程序......
(1)旧应用程序使用:打开/追加,写入,关闭 (2)新应用程序使用:打开/创建,写入,睡眠,写入,睡眠,写入,关闭。
FSW为我提供了旧应用行为的更改事件,但没有 对于新的。 FSW Notifyfilters.Size不能像我一样工作 预期。因此,无法使用FSW监视新应用程序的日志。 我找不到解决方法来使chnaged事件触发大小更改 单独
但这仍然存在:是Windows Server 2008! Windows Server 2003和 Linux with mono甚至为你提供了改变的事件(2)!!!!!所以, 我的“头衔”并不那么糟糕; - )
现在对.Net感到不满......
如果有人有想法,请现在就让我!!
对于我粗心的第一次分析而感到抱歉......; - )
BR, ++ mabra
答案 0 :(得分:0)
就这个案子而言,有人在看这个......
我在MS.Connect上打开了一个问题 - 几个星期前 - 他们 把它指向VS团队。
坏消息来自今天,他们首先设定问题 “不会修复”然后关闭。
我认为这是间接确认错误,这是 不会修复。
我完全失望了。
无论如何,最好的问候,
++ mabra