Windows Explorer的粘贴时删除（delete on paste）机制异常行为咨询与实现疑问

我非常理解你现在遇到的困扰——Windows Explorer作为源端时，和官方文档描述的粘贴删除（delete on paste）逻辑完全不符的行为确实很棘手，尤其是优化移动（optimized move）场景下的格式标记处理。

先帮你梳理文档理论和实际Explorer行为的冲突点，再给出针对目标端的正确处理方案：

文档描述的理想逻辑 #

首先回顾官方文档中关于粘贴时删除的核心规则：

如果目标端未执行优化移动，会调用IDataObject::SetData方法，将CFSTR_PERFORMEDDROPEFFECT格式设置为DROPEFFECT_MOVE；粘贴完成后，目标端再调用IDataObject::SetData将CFSTR_PASTESUCCEEDED格式设置为DROPEFFECT_MOVE。
当源端的IDataObject::SetData收到CFSTR_PASTESUCCEEDED且值为DROPEFFECT_MOVE时，需要检查是否同时收到了CFSTR_PERFORMEDDROPEFFECT且值为DROPEFFECT_MOVE：

• 两者都收到：源端必须删除数据
• 只收到CFSTR_PASTESUCCEEDED：源端只需从显示中移除数据
• 传输失败：源端恢复显示为原始状态

按照文档，作为执行优化移动的目标端，你应该只设置CFSTR_PASTESUCCEEDED为DROPEFFECT_MOVE，不触碰CFSTR_PERFORMEDDROPEFFECT。但你的测试结果完全相反，这是因为Windows Explorer的实现和文档存在差异。

针对Windows Explorer源端的正确处理方案 #

Explorer作为系统自带的Shell源端，对这两个格式标记的处理有自己的特殊逻辑，你需要调整目标端的通知方式：

1. 当优化移动成功完成时 #

不要设置CFSTR_PASTESUCCEEDED或CFSTR_PERFORMEDDROPEFFECT中的任何一个。

• 优化移动的本质是源端（Explorer）和目标端约定：目标端已经接管了文件的所有权/位置，Explorer会自行处理文件的显示移除（而非永久删除）。
• 你测试中只要设置CFSTR_PASTESUCCEEDED就会触发Explorer永久删除，这是因为Explorer把这个标记直接当作了“可以永久删除源文件”的信号，完全忽略了文档中“检查是否同时收到CFSTR_PERFORMEDDROPEFFECT”的逻辑。

2. 当优化移动失败时 #

同时设置两个格式标记：

// 伪代码示例
dataObject->SetData(CFSTR_PASTESUCCEEDED, DROPEFFECT_NONE);
dataObject->SetData(CFSTR_PERFORMEDDROPEFFECT, DROPEFFECT_NONE);

• 这样Explorer会明确收到“移动失败”的通知，恢复文件的正常显示（不再灰显），也不会删除文件。

对你测试场景的解释 #

你测试中没有实际移动文件，但Explorer的行为完全依赖你发送的格式标记：

• 发送CFSTR_PASTESUCCEEDED：Explorer认为移动已完成，直接执行永久删除（这是Explorer实现上的“过度处理”）
• 只发送CFSTR_PERFORMEDDROPEFFECT = DROPEFFECT_NONE：Explorer认为移动被取消，但未收到明确的失败通知，所以保持文件灰显（状态同步bug）

额外验证建议 #

• 如果你实际完成了优化移动（而非测试假操作），尝试不设置任何格式标记，观察Explorer是否会正确移除文件显示（而非永久删除）
• 可以参考微软官方的Shell优化移动示例代码，里面会针对Explorer的特殊行为做适配处理

内容来源于stack exchange