Windows API MoveFile()对运行中EXE无效问题咨询

这个问题其实戳中了Windows系统对正在运行的可执行文件的资源管理逻辑，咱们一步步说清楚：

核心原因：MoveFile的「延迟删除」机制 #

当你在程序里调用MoveFile(argv[0], "dst.exe")时，因为当前进程正持有原EXE文件的打开句柄（程序运行时系统会加载并锁定这个文件的访问权限），Windows无法立即移除源文件的目录条目——毕竟进程还在依赖它的内存映射呢。

这时候MoveFile会自动触发一个 fallback 逻辑：

• 先完整复制源文件的内容到目标路径dst.exe；
• 然后给原program.exe标记一个「所有打开句柄关闭后自动删除」的属性。

所以你在程序挂起（getchar()等待输入）时看到原文件还存在，完全是正常现象——因为进程还没退出，句柄没释放，系统不敢删它。等你按下回车让程序结束，进程释放了EXE文件的句柄，原program.exe会立刻被系统删除，只剩dst.exe，这才是MoveFile的真实移动效果。

为什么手动剪切粘贴运行中的EXE可以？ #

你提到的「运行时自由剪切粘贴EXE」，本质上和MoveFile的逻辑是一样的：Windows资源管理器（Explorer）执行剪切操作时，遇到正在运行的EXE，也是先复制文件到目标位置，再给源文件标记延迟删除，只是它没告诉你这个后台操作而已。你如果在程序运行完再回去看原路径，会发现源文件已经消失了。

验证方法 #

你可以自己测试一下：

• 编译打开MoveFile注释的程序，运行后让它挂在getchar()；
• 此时查看目录，确实会同时存在program.exe和dst.exe；
• 按下回车让程序退出，再刷新目录，program.exe就会消失，只剩dst.exe。

补充：关于Windows运行中EXE的操作限制 #

你说的「Windows中运行的EXE可重命名、移动但无法删除」，其实更准确的说法是：

• 重命名/移动：只要文件打开时设置了FILE_SHARE_READ | FILE_SHARE_DELETE的共享权限（EXE加载时默认就是这个权限），就可以执行，本质是修改文件的目录条目，不影响进程的内存映射；
• 删除：必须等所有持有该文件句柄的进程都退出，才能真正删除——因为删除是移除文件的所有磁盘关联，进程还在运行的话，系统无法释放对应的资源。

内容的提问来源于stack exchange，提问作者Arxz