我有一段代码使用带有 FO_MOVE 操作的 windows SHFileOperation 函数。指定的其他标志是 FOF_NOCONFIRMATION | FOF_NOERRORUI | FOF_静音。
当目标驱动器已满时,观察到一种特别奇怪的行为。在这种情况下,MOVE 无法将文件放入目标文件夹,但源文件也丢失了。这是非常出乎意料的,这会导致数据丢失。
这是 SHFileOperation 的标准行为吗?如果目标驱动器有空间,我们可以有类似 MOVE 的东西,否则将文件留在原始位置?
我有一段代码使用带有 FO_MOVE 操作的 windows SHFileOperation 函数。指定的其他标志是 FOF_NOCONFIRMATION | FOF_NOERRORUI | FOF_静音。
当目标驱动器已满时,观察到一种特别奇怪的行为。在这种情况下,MOVE 无法将文件放入目标文件夹,但源文件也丢失了。这是非常出乎意料的,这会导致数据丢失。
这是 SHFileOperation 的标准行为吗?如果目标驱动器有空间,我们可以有类似 MOVE 的东西,否则将文件留在原始位置?
我没听说过 - 听起来像是一个 BUG。
最好选择更实用的方法,将移动操作拆分为 FO_COPY,然后是 FO_DELETE(假设 FO_COPY 操作成功)。
此外,如果您的实施可以检测源卷和目标卷何时相同,您可能会获得一些效率。在这种情况下,您应该能够恢复到 FO_MOVE。同一卷上的移动操作通常会归结为重命名 + 元数据移动。
SHFileOperation 应该返回 DE_FILE_TOO_LARGE (0x85),以防目标文件对于目标媒体或文件系统来说太大。