winapi - Windows 投影文件系统只读？

Question

我试着玩弄 Projected File System实现用户模式 ​​ram 驱动器(以前我使用过 Dokan)。我有两个问题:

这是只读投影吗？从记事本打开文件并写入文件时，我找不到任何发送给我的通知。

使用 PrjWriteFileData() 后，文件是否实际创建在磁盘上？据我了解，是的。

在这种情况下，如果没有写入投影文件，那么人们可以用这个库做些什么有用的事情？在我看来，唯一有用的事情是最初从其他地方(例如远程仓库)创建一个目录树，但除此之外别无其他。多坎似乎仍然是要走的路。

Answer 1

简答:

它是 不是 只读但你不能写你的文件 直接通过投影的“源”文件系统。

WriteFileData方法用于在“临时”(投影)文件系统上填充占位符文件，因此，它不会影响“源”文件系统。

长答案:

正如@zett42 的评论中所述，ProjFS 主要设计为远程 git 文件系统。因此，任何文件版本控制系统的主要目标都是处理文件的多个版本。由此产生了一个问题 - 我们是否需要在 ProjFS 文件写入时覆盖远程存储库中的文件？这将是灾难性的。使用 git 时，您总是在本地写入文件，并且在将更改推送到远程存储库之前它们不会同步。

当您枚举文件时，没有任何内容写入本地文件系统。从 ProjFS 文档:

When a provider first creates a virtualization root it is empty on the local system. That is, none of the items in the backing data store have yet been cached to disk.

只有在打开文件后，ProjFS 才会在本地文件系统中为它创建一个“占位符”——我假设它是一个具有特殊结构的文件(不是真实的)。

As files and directories under the virtualization root are opened, the provider creates placeholders on disk, and as files are read the placeholders are hydrated with contents.

“水合”是什么意思？最有可能的是，它代表了一种特殊的数据结构，部分填充了真实数据。我会将占位符想象成一块部分填充数据的海绵。

As items are opened, ProjFS requests information from the provider to allow placeholders for those items to be created in the local file system. As item contents are accessed, ProjFS requests those contents from the provider. The result is that from the user's perspective, virtualized files and directories appear similar to normal files and directories that already reside on the local file system.

只有在文件被更新(修改)之后。它不再是占位符——它变成了“完整文件/目录”:

For files: The file's content (primary data stream) has been modified. The file is no longer a cache of its state in the provider's store. Files that have been created on the local file system (i.e. that do not exist in the provider's store at all) are also considered to be full files.

For directories: Directories that have been created on the local file system (i.e. that do not exist in the provider's store at all) are considered to be full directories. A directory that was created on disk as a placeholder never becomes a full directory.

这意味着在第一次写入时，占位符被本地 FS 中的真实文件替换。但是如何使“远程”文件与修改后的文件保持同步？ (1)

When the provider calls PrjWritePlaceholderInfo to write the placeholder information, it supplies the ContentID in the VersionInfo member of the placeholderInfo argument. The provider should then record that a placeholder for that file or directory was created in this view.

请注意“提供商应记录该文件的占位符”。这意味着为了稍后与 同步文件正确 View 表示我们必须记住修改后的文件与哪个版本相关联。想象一下，我们在一个 git 存储库中，并且我们更改了分支。在这种情况下，我们可能会更新一个文件 多次 在不同的分支。现在，提供者为什么以及何时调用 PrjWritePlaceholderInfo ?

... These placeholders represent the state of the backing store at the time they were created. These cached items, combined with the items projected by the provider in enumerations, constitute the client's "view" of the backing store. From time to time the provider may wish to update the client's view, whether because of changes in the backing store, or because of explicit action taken by the user to change their view.

再一次，想象在 git 存储库中切换分支；如果文件在另一个分支中不同，则必须更新文件。继续回答问题(1)。想象你想从一个特定的分支进行“推送”。首先，你要知道哪些文件被修改了。如果您在修改文件时没有记录占位符信息，您将无法正确执行(至少对于 git 存储库示例)。

请记住，占位符在修改时被真实文件替换？ ProjFS 具有 OnNotifyFileHandleClosedFileModifiedOrDeleted事件。这是回调的签名:

public void NotifyFileHandleClosedFileModifiedOrDeletedCallback(
    string relativePath,
    bool isDirectory,
    bool isFileModified,
    bool isFileDeleted,
    uint triggeringProcessId,
    string triggeringProcessImageFileName)

对于我们的理解，这里对我们来说最重要的参数是 relativePath .它将包含“暂存”文件系统(投影)内的修改文件的名称。在这里您还知道该文件是一个真实的文件(不是占位符)并且它被写入磁盘(也就是说，您将无法在 文件被写入之前拦截调用 )。现在您可以将其复制到所需的位置(或稍后再做)——这取决于您的目标。

回答问题#2，好像是PrjWriteFileData仅用于填充“临时”文件系统，不能用于更新“源”文件系统。

应用:

对于应用程序，您仍然可以实现远程文件系统(而不是使用 Dokan)，但所有写入都将在本地缓存，而不是直接写入远程位置。几个用例想法:

分布式文件系统

在线驱动客户端

文件系统“调度程序”(例如，您可以根据特定条件将文件写入不同的文件夹)

文件版本控制系统(例如，您可以在修改后保留同一文件的不同版本)

将数据从您的应用程序镜像到文件系统(例如，您可以“投影”带有缩进文件夹、子文件夹和文件的文本文件)

PS:我不知道任何未记录的 API，但从我的角度来看(根据文档)，我们不能将 ProjFS 用于 ramdisk 或直接将文件写入“源”文件系统而不将它们写入“本地”文件系统。