-
Notifications
You must be signed in to change notification settings - Fork 453
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Where is GvFlt filter driver source code? #5
Comments
Nope, that's not it. There's a nuget package referenced in packages.config. The package is Microsoft.GVFS.GVFlt, and it's that package that includes the .sys file. If we're not getting the source code to the filter driver, at least give it a proper digital signature so that we can use this without enabling test signing. Requiring test signing only makes sense when we're building the driver ourselves. |
The GvFlt filter driver is currently only available as a test-signed preview. I will share more detail about when/how it will be released as soon as I know more. |
A driver that could serve as a model for a network-backed "virtual" filesystem on Windows could find applications beyond git. I don't know if this driver would necessarily serve such a role, but I feel like it could. This wouldn't completely close the weakness that Windows suffers from not having FUSE, but it would help. |
Huh, so this blog post describes the driver as the "moral equivalent" of FUSE and says that the Windows team is involved. Does this mean that we're going to get an extensible signed version of the driver so that we can finally have FUSE for Windows? |
Will the eventual open sourcing of the file system filter driver be under a more favorable license than the EULA currently allows (which restricts to use with GVFS or for "internal business purposes")? Specifically, I'm looking for the freedom to fork the code for non-GVFS use cases, including scenarios that may not fall under "internal business purposes." |
The current GvFlt EULA is a bit restrictive because GvFlt is simply not ready to ship yet, and we're not ready to make any claims about its quality, or to service it. That said, we wanted to get GVFS out there as soon as possible, and didn't feel that it made any sense to release the user mode code without at least a functioning preview of the kernel mode driver too. That said, we're very keen to get GvFlt out there as soon as we can. We just have a few issues to sort through before we can finalize the details of how we will release it. |
I bit of offtopic, still maybe relevant:
I may look cpt. obvious-like, but there are two other open source projects which do this + have FUSE wrappers too: https://github.com/dokan-dev/dokany (LGPL 3.0) There was also Fuse4win, but it seems defunct and found only as a snapshot: |
Back to the original question of GvFlt source code: GvFlt is a generic driver to support user mode file system driver extensions on Windows – there is absolutely nothing about Git in it. It’s an odd historical artifact that it’s called GvFlt and I doubt that name will endure. A year or so ago, when we settled on the basic approach for GVFS, we asked the Windows file system team to help us (we, the Git team, really aren’t experts at file system drivers and they are hard to get right). The Windows team built GvFlt for this as well as other engineering scenarios which benefit from file abstraction. To us, the Git team, we were taking a dependency on a Windows feature expecting at some point it would ship as a fully supported part of Windows. Given the interest in seeing the source, the Windows team has said they’ll explore open sourcing it but not until they sort out how it lands in a Windows release. As we look at porting GVFS to other platforms (and we do plan to), we’ll obviously be using OS mechanisms native to those platforms – GvFlt is entirely Windows specific. |
Any news on this? |
pass permissions mode when hydrating directories
I don't install unsigned drivers unless I am really sure. Can you please point me to the repository for this or make it available if not done already?
The text was updated successfully, but these errors were encountered: