CuffFielEX可以与卷柄一起使用吗?

我在试验 FSCTL_MOVE_FILE . 大多数情况下一切都按预期进行。但是,有时如果我试图重读(通过 FSCTL_GET_NTFS_FILE_RECORD )我刚移动的mft记录,我得到了一些坏数据。

具体来说,如果文件记录说$attribute_list属性是非驻留的,并且我使用卷句柄从磁盘读取数据,我会发现其中的数据内部不一致(记录长度大于数据的实际长度)。

我一看到这种情况,原因就很清楚了:在NTFS驱动程序写完之前,我正在阅读记录。调试支持这一理论。但知道这并不能帮我解决问题。我使用同步方法 fsctl_move_文件 调用,但显然文件系统仍然可以在后台更新内容。隐马尔可夫模型。

在正常的档案里,我会想 LockFileEx 有一个共享锁(因为我只是在看书)。但我不确定这对音量控制有什么意义?我更不确定ntfs在内部使用这种机制来确保一致性。

不过,这似乎是个开始的地方。但是我的 锁定文件 对卷句柄的调用正在返回 ERROR_INVALID_PARAMETER . 我不知道哪个参数可能出错,除非是卷句柄本身。也许他们就是不支持锁?或者我应该插上一些特别的旗子 CreateFile 打开音量手柄时?我试过启用 SE_BACKUP_NAME 和 FILE_FLAG_BACKUP_SEMANTICS ,但错误保持不变。

向前看,我可以看到以下几种选择:

1. 找出如何使用卷句柄锁定分区(并希望ntfs驱动程序也这样做)。在这一点上似乎很可疑。
2. 找出如何刷新刚刚移动的文件的元数据(注意:flushfilebuffers for the move_file_data.filehandle没有帮助)。可能冲洗音量手柄?).
3. 是否有一些“官方”方法来读取非本地数据 ReadFile 对着音量手柄?我没有找到,但也许我错过了。
4. 移动数据后等待“一点”,让驱动程序完成所有更新。讨厌。

fwiw,这里有一些针对卷句柄执行lockfileex的测试代码。请注意,必须以管理员身份运行才能锁定卷句柄。我在用 J: ,因为那是我的闪存。50000是随机挑选的,但应该小于闪光灯驱动器的大小。

void Lock()
{
    WCHAR path[] = L"\\\\.\\j:";

    HANDLE hRootHandle = CreateFile(path,
                             GENERIC_READ, 
                             FILE_SHARE_READ | FILE_SHARE_WRITE, 
                             NULL, 
                             OPEN_EXISTING, 
                             0, 
                             NULL);

    OVERLAPPED olap;
    memset(&olap, 0, sizeof(olap));
    olap.Offset = 50000;

    // Lock 1k of data at offset 50000
    BOOL b = LockFileEx(hRootHandle, 1, 0, 1024, 0, &olap);
    DWORD j = GetLastError();

    CloseHandle(hRootHandle);
}

查看错误数据的代码是…相当投入。然而,它是容易复制的。当它失败时,我会尝试读取长度为“0”的可变长度$attribute_list条目,这会导致无限循环,因为看起来我从未读取完整个缓冲区。如果长度为零,我就退出它,但我担心缓冲区中的“剩余垃圾”而不是干净的零。发现那是不可能的,所以我希望有更好的解决方案。

不足为奇的是,这方面的信息并不多。所以如果有人有经验的话,我需要一些洞察力。

编辑1:

更多不太管用的事情:

• 洛克菲莱克斯还是不走运。
• 我试着冲洗音量手柄(正如保罗建议的那样)。虽然这有效,但我的执行时间却增加了一倍多。而且,严格地说,它仍然不能解决问题。仍然不能保证ntfs不会在flushfilebuffers和fsctl-get-ntfs-file-record/readfile之间做更多的改变。
• 我想知道$standard_information属性的“recordchanged”时间戳。但是,由于属性列表的这些更改,它不会被更改。
• 对文件进行分段最终会导致添加属性列表,并且随着分段的继续增加,将有更多的数据记录添加到该列表中。当数据记录被添加时,updatesequencenumber(不是mft_段引用的一部分,而是另一部分)将被更新。不幸的是,有一系列事件要执行此更新。显然,属性列表缓冲区'length'在'updatesequencenumber'之前更新。因此,查看“updatesequencenumber”是否已更改,无助于避免读取(潜在的)错误信息。

我的下一个最佳想法是,在更新记录长度之前(或者在记录长度缩减时),看看ntfs是否总是将新字节归零。如果我可以将记录长度设为零(而不是剩余的数据可能占用这些字节),我可以假装调用这个固定的。