如果目标驱动器已满，SHFileOperation FO_MOVE 将删除文件
我有一段代码，它使用 Windows SHFileOperation 函数和 FO_MOVE 操作。指定的其他标志为 FOF_NOCONFIRMATION | FOF_NOERRORUI | FOF_SILENT。
当目标驱动器已满时，会观察到一种特别奇怪的行为。在这种情况下，MOVE 无法将文件放入目标文件夹，但源文件也丢失了。这是非常出乎意料的，并且导致了数据丢失。
这是 SHFileOperation 的标准行为吗？ 如果目标驱动器有空间，我们可以进行类似 MOVE 的操作，否则将文件保留在原始位置吗？
I had a piece of code which uses windows SHFileOperation function with FO_MOVE operation. Additional flags specified were FOF_NOCONFIRMATION | FOF_NOERRORUI | FOF_SILENT.
A particular weird behavior was observed when the destination drive was full. In this case, MOVE could not place the file in destination folder but the source file was also lost. This was highly unexpected and this caused a loss of data.
Is this the standard behavior of SHFileOperation?
Can we have something like MOVE if the destination drive has space otherwise leave the file at the original place?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我没听说过这个——听起来像是一个BUG。
最好选择更实用的方法，将移动操作拆分为 FO_COPY，然后是 FO_DELETE（假设 FO_COPY 操作成功）。
此外，如果您的实施可以检测源卷和目标卷何时相同，您可能会提高一些效率。在这种情况下，您应该能够恢复到 FO_MOVE。同一卷上的移动操作通常会简化为重命名+元数据移动。
I've not heard of this - sounds like a BUG.
May be best to choose the more pragmatic approach, by splitting the move operation into FO_COPY, followed by FO_DELETE (assuming the FO_COPY operation succeeded).
Additionally, you might gain some efficiency if your implementation could detect when the source and destination volumes are the same. In this case, you should be able to revert to FO_MOVE. A move operation on the same volume generally distills down to a rename + metadata move.
如果目标文件对于目标媒体或文件系统来说太大，SHFileOperation 应返回 DE_FILE_TOO_LARGE (0x85)。
The SHFileOperation should return DE_FILE_TOO_LARGE (0x85) in case the destination file is too large for the destination media or file system.