我有一个处理inetpub/mailroot/Queue目录中的电子邮件的侦听器。 一旦收听者完成处理电子邮件，它将继续将电子邮件移动到另一个目录。 但是，由于进程inetinfo.exe的文件locking，移动电子邮件是不可能的。 我已经注意到，这个文件locking在几个小时到几天的时间段之后被释放。 您可以看到Queue目录随着时间的推移可能变得非常充实。
我已经能够解决这个问题的唯一方法是通过在IIS中手动停止并启动我的SMTP虚拟服务器。
是否有可能以编程方式释放此文件locking？ 如果没有，是否有可能加快释放这个文件锁？
UPDATE
监听器监视传入电子邮件的Queue文件夹，然后处理它们。 然后将电子邮件中的数据插入到我们的内部程序中。 听者完成电子邮件后，将电子邮件移到其他地方的成功或失败目录。
解决了
一年之后回到这个问题后，终于能解决了！ 解决scheme是configurationSMTP虚拟服务器的本地（默认）域，并将其设置为我想处理的电子邮件的适当域。 这导致电子邮件进入Drop文件夹，在那里他们可以自由操纵，而不必担心stream程locking。
“队列”目录是供SMTP服务器进程内部使用的。 你find的文件locking在那里，因为你不应该在那里工作。 如果您的“队列”目录正在填满，那么您最好弄清楚为什么电子邮件递送失败。 目前还不清楚微软的旧SMTPDiag工具是否可以在Windows Server 2008上运行，但这是一个开始的地方。
更新：
我不清楚你正在处理你的任务。 “队列”文件夹用于保存等待传送的消息。 已经接受本地传送的信息存储在“Drop”文件夹中。 假设你正在寻找正在接受本地交付的消息，我会关心他们为什么要挂在“队列”，而不是在“放弃”结束。 除非某些工作不正确，否则不应该在“队列”中build立文件。
（顺便说一句：查找文档：Windows Server 2008中的SMTP服务变得相当困难，SMTP服务一直都是孤儿，生活在Windows操作系统和Exchange之间的黑暗世界里>叹息< ）
在registry中有一些参数来控制locking时间…
但保持容易…
只要重新启动IIS（如每n分钟计划的任务），如果您使用IIS 7.0这样做…
// stop iis and other web services net stop WAS // ( pause a few seconds, +30s ) >>> Do your processing... files should be released now... // start iis and web services net start W3SVC