问在win32控制台应用程序中使用ntdll.dll好吗？

EN

简而言之:在我的c++项目中，我需要读/写扩展文件属性。我使用备用数据流(ADS)来管理它。我的问题是，为了打开广告，我需要使用CreateFile应用程序接口。但它并没有满足我的需求。NtCreateFile将完全满足我的所有需求。(或者选择NtSetEaFile和NtQueryEaFile)，但是不能从win32控制台应用程序直接访问NtCreateFile。

我知道我可以通过GetProcAdres很容易地使用这个函数。但是如果我遗漏了什么，我想知道你们所有人的意见。其他一些库已经在使用这种模式，例如Chromium (https://github.com/chromium-googlesource-mirror/chromium/blob/1c1996b75d3611f56d14e2b30e7ae4eabc101486/src/sandbox/src/win_utils.cc function：ResolveNTFunctionPtr)，但我不确定，因为c++项目不是一个爱好项目，我问自己它是否危险。

我猜NtCreateFile可能是最安全的方式，因为它有很好的文档记录和winternl.h header的支持。尤其是因为该方法自Windows2000以来没有改变。但是NtSetEaFile和NtQueryEaFile是什么，它们完美地满足了我的需求。它们只有一半记录在案。存在用于ZwSetEaFile和ZwQueryEaFile的文档(自Windows2000以来未更改)。

我想这么做的原因：

我想通过ADS从文件中写入和读取扩展属性。但在第一次编写给定文件的扩展属性时，我需要使用OPEN_ALWAYS打开该文件。如果文件不存在，它将创建一个新文件，即使我只访问不是该文件的内容流。为了避免这种情况，我首先获取原始文件的句柄，然后使用该句柄检查该文件是否仍然存在。但我不想写任何访问权限降低的文件，因为从我的角度来看，这是一个非常糟糕的模式。用户需要随时拥有对任何文件的完全访问权限。因此，我们使用标志FILE_SHARE_DELETE | FILE_SHARE_READ | FILE_SHARE_WRITE打开所有句柄。现在我有比赛了。

auto hFile = CreateFileW(originalPath, …, FILE_SHARE_DELETE | FILE_SHARE_READ | FILE_SHARE_WRITE, …).
// this is the little race: if somebody at least rename originalPath the
// second CreateFileW call will cause the creation of a empty file with the
// path originalPath (the old path).
auto hADS = CreateFileW(originalPath + adsName, …, FILE_SHARE_DELETE | FILE_SHARE_READ | FILE_SHARE_WRITE, OPEN_ALWAYS, …).

这是一个主要问题，特别是因为在我们的测试中这种情况时有发生。NtCreateFile将修复它，因为我可以在第一个HANDLE的帮助下创建第二个HANDLE。正因为如此没有比赛。或者NtSetEaFile和NtQueryEaFile会有所帮助，因为我只需要一个句柄。

问题是，应用程序不需要为将来保存，因为ADS无论如何都只能在NTFS上工作。谁知道什么时候NTFS会被交换。但是我不想要一个古怪的行为。我想相信这个方法。如果API在未来会发生变化，软件需要适应它，我会很好。但我想确定的是，所有高于或等于7的Windows都可以处理它。有人可以分享一些经验吗？我非常想听到他们的声音。