WinFsp 实战指南三步在 Windows 上挂出属于自己的虚拟磁盘全程不碰内核代码【免费下载链接】winfspWindows File System Proxy - FUSE for Windows项目地址: https://gitcode.com/gh_mirrors/wi/winfsp在 Windows 里凭空多出一个磁盘通常意味着你得先学会内核驱动开发——而这篇指南要告诉你的是借助 WinFspWindows File System Proxy即 Windows 平台的 FUSE 实现你只需要写一个普通用户态程序就能让系统识别并挂载一个完全由你掌控的文件系统。第一章 一个真实的业务痛点为什么造一个磁盘过去那么难想象这样一个场景产品经理走到你工位前说我们想把云存储做成一个盘用户双击就能用就像本地磁盘一样。你心里清楚这在 Linux 上早有现成答案——FUSEFilesystem in Userspace能让普通程序摇身一变成为文件系统。可在 Windows 上呢传统的做法只有一条路写内核模式文件系统驱动FSD。这条路有多难内核代码没有用户态那样的保护一个空指针解引用就可能让整个系统蓝屏调试要挂双机、开 WinDbg、分析蓝屏转储还要处理 IRP、快速 I/O、缓存管理器、内存映射等一系列 Windows 独有的机制。哪怕你只想要一个能读写文件的简单盘也需要几个月的时间投入。更别提驱动一旦上线每次 Windows 更新都可能是新的噩梦。换句话说功能诉求很简单技术门槛却很陡峭。这中间的落差正是 WinFsp 想要填平的。WinFsp 的思路非常直白把文件系统这个内核概念搬到用户态来。它自己不关心你的数据放在哪、怎么组织它只负责两件事——在系统面前扮演一个货真价实的文件系统驱动以及把你写的普通程序接到这个驱动的背后。于是造一个磁盘这个任务就从内核编程降级成了写一个实现回调函数的控制台程序。那么这个替身到底是怎么工作的接下来我们把它的内脏拆开看看。第二章 拆开看内脏WinFsp 究竟替你扛下了什么先用一句话概括架构内核里有一个驱动负责冒充用户态有一个 DLL 负责传话而你的代码只负责干活。层面组件职责内核模式文件系统驱动FSD注册为真正的文件系统驱动处理 IRP、与缓存管理器协作、向 Windows 呈现卷用户模式WinFsp DLL与 FSD 通信把内核请求翻译成一组回调函数派发给你的程序你的程序自定义文件系统实现 Create/Read/Write 等回调决定数据到底存在哪在代码仓库里你可以在 src/sys/ 找到那个内核驱动在 src/dll/ 找到用户态 DLL。前者是 WinFsp 团队多年打磨的成果你基本不需要碰它后者暴露给你的是一张操作表。我们跟踪一次最简单的打开文件请求看看整条链路长什么样记事本调用CreateFileW(X:\\hello.txt, ...)Windows 的文件系统分发器识别出X:是 WinFsp 卷把请求以 IRP 形式发给内核 FSDFSD 通过内部端口把请求转发给用户态 DLLDLL 从请求队列中取出这次操作调用你注册的Open回调你的函数返回STATUS_SUCCESS结果沿原路返回记事本心满意足地打开了文件。整个过程里你的程序完全不知道 IRP 是什么也不需要关心缓冲区如何映射——这些都被 WinFsp 封装掉了。你唯一要做的是把操作表填满然后启动一个分发器循环坐在那里等待操作系统敲门。听起来有点像给系统装了一个可编程的替身表面上是货真价实的磁盘背后其实是你的代码在逐条应答。这不只是开发体验的提升还有一个隐藏的稳定性红利你的文件系统崩溃了最多是那个盘消失系统不会蓝屏——因为真正的驱动FSD依然健在。理论讲得差不多了咱们来点实际的——先不写代码把现成的例子跑起来。第三章 十分钟挂载出第一个文件系统从 MEMFS 开始MEMFS 是 WinFsp 自带的示例内存文件系统全部数据都存在内存里代码位于 tst/memfs/。它体量小、覆盖全是官方钦定的入门教材。先做好两件事克隆仓库git clone https://gitcode.com/gh_mirrors/wi/winfsp下载安装 WinFsp务必勾选 Developer 组件——只有选了它才会带 MEMFS 示例、头文件和库文件。装好后打开命令行一行命令把 MEMFS 挂到X:盘net use X: \\memfs64\test如果一切顺利你会看到这样的输出挂载成功后X:就是一个完全正常的磁盘了。验证一下X: echo hello world hello.txt dir type hello.txt你能在资源管理器里看到它能新建文件、建目录、改属性甚至设置访问权限——所有 Windows 文件 API 对它一视同仁。而此刻在幕后MEMFS 进程正守在一个循环里等待内核把一个个操作请求递进来。这个十秒钟看到成果的体验正是 WinFsp 设计哲学的第一课让入门者先看到希望再谈原理。挂载只是入口真正值得琢磨的是 MEMFS 那两千多行代码——尤其是那张操作表。下一章我们就逐行读它。第四章 读懂那张操作表文件系统的全部秘密都在接口里打开 tst/memfs/memfs.cpp往下翻到MemfsInterface你会看到一段结构体初始化——这就是文件系统的操作表static FSP_FILE_SYSTEM_INTERFACE MemfsInterface { GetVolumeInfo, /* 卷容量、卷标等信息 */ SetVolumeLabel, GetSecurityByName, /* 按文件名查询安全描述符 */ Create, /* 创建文件/目录 */ Open, /* 打开已有文件 */ Overwrite, /* 覆盖写 */ Cleanup, /* 句柄清理 */ Close, /* 最后关闭 */ Read, /* 读数据 */ Write, /* 写数据 */ Flush, /* 刷盘 */ GetFileInfo, /* 查询文件信息 */ SetBasicInfo, /* 修改时间戳/属性 */ SetFileSize, /* 修改文件大小 */ CanDelete, /* 询问可以删除吗 */ Rename, /* 重命名/移动 */ GetSecurity, SetSecurity, ReadDirectory, /* 枚举目录 */ /* ... 后续还有重解析点、命名流、扩展属性等可选回调 */ };注意这里我没贴真实的完整代码——实际文件里因为条件编译宏的存在很多位置是0占位符。但这恰好透露了一个重要信息回调函数是可裁剪的。不需要的功能就填NULLWinFsp 会自动帮你处理未实现的情况。这就像一份可勾选的菜单你只管填自己擅长的菜。读这张表时建议按三组来理解卷级操作GetVolumeInfo、SetVolumeLabel回答这个盘多大、卷标是什么文件级操作Create、Open、Read、Write、Rename…回答文件怎么生、怎么读、怎么写、怎么删增强功能重解析点、命名流、扩展属性回答要不要支持 Windows 的高级特性。再看一个具体回调的体型——Read函数的签名static NTSTATUS Read(FSP_FILE_SYSTEM *FileSystem, PVOID FileNode0, PVOID Buffer, UINT64 Offset, ULONG Length, PULONG PBytesTransferred) { MEMFS_FILE_NODE *FileNode (MEMFS_FILE_NODE *)FileNode0; if (Offset FileNode-FileInfo.FileSize) return STATUS_END_OF_FILE; /* 读超出文件末尾 */ /* 把数据拷贝到 Buffer更新 *PBytesTransferred返回 STATUS_SUCCESS */ }读这个函数你能立刻感受到回调式文件系统的本质内核把谁、在哪、读多少、读到哪都告诉你了你要做的只是找到数据、填进缓冲区、报告读了多少字节。FileNode0是你自己的上下文指针——你可以在打开文件时任意绑定自己的数据结构读写时原样取回。数据到底来自内存、数据库还是远端服务器WinFsp 完全不关心。操作表填好后剩下的就是组装与启动典型的生命周期如下FspFileSystemCreate(DevicePath, VolumeParams, MemfsInterface, Memfs-FileSystem); FspFileSystemStartDispatcher(Memfs-FileSystem, 0); /* 进入请求分发循环 */ /* ... 程序主循环在此驻留 ... */ FspFileSystemStopDispatcher(Memfs-FileSystem); FspFileSystemDelete(Memfs-FileSystem);其中VolumeParams是卷的体检报告扇区大小、文件系统名、是否大小写敏感、是否支持命名流、是否支持重解析点……这些参数直接决定了 Windows 会如何对待你的卷。在 tst/memfs/memfs.cpp 的MemfsCreateFunnel里你能看到一长串VolumeParams赋值——那是理解卷能力声明的最佳教材。写到这里你可能已经冒出一个疑问回调写得再顺性能会不会很差毕竟数据要绕一大圈。下一章我们拿数据说话。第五章 凭什么叫板 NTFS性能数据与三个调优旋钮用户态文件系统 慢这是最流行的刻板印象。WinFsp 用一张又一张实测图表回应了这个质疑。官方性能测试文档位于 doc/WinFsp-Performance-Testing.asciidoc测试数据则沉淀在 doc/WinFsp-Performance-Testing/ 目录的 CSV 与图表里。从图表可以直观看到以内存为后端的 MEMFS在很多文件操作上不仅没有拖后腿反而压过了 NTFS——文件创建、删除这类元数据密集操作尤其明显。为什么能这么快答案藏在这几个设计里内核缓冲池与批量传输FSD 与 DLL 之间不是一条请求走一次系统调用而是通过共享缓冲池批量搬运大幅摊薄了上下文切换成本文件信息超时缓存FileInfoTimeout文件属性不必每次都问你的程序在超时窗口内直接复用把最频繁的GetFileInfo类查询挡在了门外异步与排队模型WinFsp 支持请求排队与异步应答你的程序可以稍后完成请求把 I/O 并发度提上去。IPC 机制与状态机详见 doc/WinFsp-as-an-IPC-Mechanism.asciidoc。如果你的文件系统跑起来偏慢先别急着怀疑框架按这个顺序排查调优点手段效果属性查询频繁调大FileInfoTimeout如 MEMFS 默认设为INFINITE显著减少回调次数小请求太多利用批量接口/大缓冲区合并读写摊薄每字节开销同步阻塞严重对耗时操作返回STATUS_PENDING异步完成提升并发吞吐一句话总结性能哲学WinFsp 把快的机制做进框架里把更快的旋钮留给你。框架负责不拖后腿而你负责告诉它你的数据访问模式长什么样。性能解决之后下一个现实问题摆在面前API 这么多我该用哪个第六章 五种 API 怎么选原生、FUSE 两代、Cygwin 与 .NETWinFsp 的野心从它的 API 家族就能看出来——它不想只服务 C 开发者。盘点一下仓库里的选项API头文件/源码位置适合谁原生 WinFsp APIinc/winfsp/追求完整 Windows 特性命名流、重解析点、安全描述符的项目FUSE API for Windowsinc/fuse/ 与 inc/fuse3/想把 Linux 上的 FUSE 文件系统平移到 WindowsFUSE API for Cygwinopt/cygfuse/需要在 Cygwin 环境里跑 FUSE 生态.NET APIsrc/dotnet/C# 团队不想碰 C 的指针与头文件扩展文件系统库opt/fsext/需要文件系统之上附加扩展能力如符号链接支持怎么选给三条经验法则从零开始且要深耕 Windows选原生 API。它给你的自由度最大MEMFS 和 tst/passthrough/ 都是现成范本手头已有 Linux 文件系统选 FUSE API通常把fuse_main换成对应入口就能跑起来。仓库里的 tst/memfs-fuse3/ 和 tst/passthrough-fuse3/ 展示了迁移后的模样团队以 C# 为主直接用 .NET 包装逻辑可以完全用托管代码写。这里特别提醒一句能用 FUSE API不等于原样照搬 Linux。Windows 的语义和 POSIX 存在系统性差异——大小写敏感策略、路径分隔符、权限模型、删除语义处处是坑。WinFsp 专门写了 doc/Native-API-vs-FUSE.asciidoc 来剖析这些差异动手移植前建议先通读一遍能帮你省下大量踩坑时间。选好了 API写完了代码事情就算完了吗当然不是——下一个战场是让它稳定地跑在别人机器上。第七章 从能跑到跑稳调试、测试与生产落地的四件事用户态文件系统有个微妙处境它既是普通进程又承担系统组件职责。想让它跑稳这四件事绕不开。第一件会看日志。WinFsp 内置了调试日志机制FspDebugLogSetHandle可以把日志导向调试器或文件配合 doc/WinFsp-Debugging-Setup.asciidoc 里描述的 WinDbg 联动方法可以同时看内核侧和用户侧的视角。开发期建议把日志级别开到最细上线后按需关闭。第二件跑测试。仓库里的 tst/winfsp-tests/ 是官方测试套件覆盖了创建、读写、锁、通知、重解析点、安全描述符等方方面面是 WinFsp 自己宣称无已知内核崩溃的底气来源。你自己的文件系统也应该照这个清单补一套回归用例。第三件想清楚进程死了怎么办。这可能是生产环境最大的坑。你的文件系统进程崩溃或被任务管理器杀掉用户手上的盘会突然消失正在写入的数据可能损坏。WinFsp 提供了 Launcher 服务机制见 doc/WinFsp-Service-Architecture.asciidoc让你的文件系统以受控方式启动、重启配合持久化设计才能扛住真实的断电和崩溃场景。第四件站在巨人的肩膀上。不妨看看这些先例SSHFS-Win 用 WinFsp 把远端目录变成了本地盘rclone 用它挂载各云存储大量商业产品用它实现自定义存储。这些项目验证的不只是能跑更是在真实环境里长期跑。想更上一层楼可以研读 doc/WinFsp-Design.asciidoc 了解其设计取舍——它是理解框架边界的最短路径。写在最后你的第一个文件系统现在就可以开始现在你只差一个动作克隆仓库、装好环境、跑起 MEMFS然后在 tst/memfs/memfs.cpp 里改一个回调、加一行日志亲眼看着你的代码决定了一个盘的行为。那扇通往 Windows 用户态文件系统的大门已经为你敞开。而在动手之后有一个问题值得你继续琢磨当磁盘不再必须是磁盘数据层与表现层彻底解耦你的业务还能长出哪些前所未有的形态毕竟WinFsp 给出的不是又一个磁盘工具而是一个把存储幻想变成现实的基础设施。【免费下载链接】winfspWindows File System Proxy - FUSE for Windows项目地址: https://gitcode.com/gh_mirrors/wi/winfsp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考