在写 《翻译《The Old New Thing》- What did MakeProcInstance do?》 文章时，了解到了 Michael Geary ，他也有不少优秀的技术文章，现翻译一篇关于文件操作的细节的文章
原文
https://mg.to/2004/09/30/file_share_delete-in-shell-extensionMichael Geary | 星期三, 2004-09-29 18:24
通过文件内容提供信息的 Windows shell 扩展必须打开文件才能实现。打开文件会在某种程度上锁定文件，这取决于您使用的文件共享标志。即使打开文件的时间很短，也足以影响其他程序对文件的使用。
如果有人将文件从一个文件夹拖到另一个文件夹，而你的外壳扩展可以为选定的文件类型显示缩略图，会发生什么情况？Windows 会调用你的 IExtractImage 接口，然后你就开始渲染缩略图。然后，只要客户松开鼠标，Windows 就会尝试将文件移动到新文件夹。如果移动速度足够快，当你还在打开文件渲染缩略图时，就会发生这种情况。结果就会出现这条可爱的信息：
如果幸运的话，他们会再试一次，速度再慢一点，这样就能成功了！你完成了缩略图的渲染，关闭了文件，Windows 就可以顺利地移动它了。
对于 Windows NT、2000 和 XP，有一种简单的方法可以解决这个问题。在打开文件的调用中，在 dwShareMode 参数中使用 CreateFile()FILE_SHARE_READ | FILE_SHARE_DELETE
MSDN 文档中并没有明确说明，但它的工作方式与 .NET Framework 中的工作方式相同。 换句话说，它为你提供了 Unix 风格的删除/重命名语义。即使您打开了文件，Windows 也可以删除它或重命名它，但您可以继续读取它--您对文件的句柄一直有效，直到您关闭它。FILE_SHARE_DELETEMoveFile()DeleteFile()
因此，在上述情况下，Windows 会将文件移动到目标文件夹，而不会受到缩略图代码的干扰。
Mike Mascari 对此进行了测试，并将结果发布在 comp.databases.postgresql.hackers 新闻组中：
这就是测试：
foo.txt 内容是 "This is FOO!"
bar.txt 内容是 "This is BAR!"
Process 1 打开 foo.txt
Process 2 打开 foo.txt
Process 1 sleeps 7.5 秒
Process 2 sleeps 15 秒
Process 1 调用 MoveFile() 改名 "foo.txt" to "foo2.txt"
Process 1 调用 MoveFile() 改名 "bar.txt" to "foo.txt"
Process 1 调用 DeleteFile() 删除 "foo2.txt"
Process 2 唤醒后显示 "This is FOO!"
在文件系统上，我们将看到:
foo.txt 内容是 "This is BAR!"
好消息是，只需使用 MoveFile() 即可在 NT 4 下正常运行。坏消息是，它要求使用设置了 FILE_SHARE_DELETE 标志的 CreateFile() 打开文件。Visual C++ 6 随附的 C 库最终会通过 fopen() 调用 CreateFile()，但无法通过标准 C 库例程使用 FILE_SHARE_DELETE 标志。而在 Windows 95/98 下，FILE_SHARE_DELETE 标志无法使用（错误参数）。这意味着，在这些平台上，似乎仍然没有解决方案。在 NT/XP/2K 下，AllocateFile() 必须修改为调用 CreateFile()，而不是 fopen()。我不清楚 ME 的情况，但我怀疑它的行为与 95/98 类似。
即使在 Mike 发表文章的两年后，C 运行时也没有什么改进。和函数声称支持文件共享，但都不支持.NET。对于 shell 扩展来说，这可能并不重要；你可以直接使用 Win32 文件 I/O 函数。如果你需要流 I/O 函数提供的缓冲功能，可以使用 打开文件 ，然后获取一个 C 运行时文件描述符，并从中打开一个流。_fsopen()_sopen()FILE_SHARE_DELETE``CreateFile()``FILE_SHARE_DELETE_open_osfhandle()_fdopen()
抱歉，在 95、98 或 Me 上无法运行；必须取消标记。我不知道如何解决这些操作系统的问题。FILE_SHARE_DELETE