[C++] FUSE applicatie porten naar Windows

[cyberstalker]

Ik wil een C++ applicatie die gebruik maakt van FUSE porten naar Windows. De applicatie is gebaseerd rond een event-loop en maakt dus gebruik van de non-blocking lowlevel api van FUSE. Nu ben ik op zoek naar de makkelijkste weg. Ik heb zover de volgende opties gevonden:

• dokany
• cbfs
• FUSE via cygwin

Zowel dokany als cbfs lijken een FUSE wrapper te hebben, wat in eerste instantie een goede optie lijkt, totdat je het gaat bekijken, want ze missen de lowlevel stuff die ik gebruik. Deze optie valt dus af.

cbfs heeft sowieso geen non-blocking API en valt dus helemaal af. Bij dokany zijn er twee branches die er iets mee lijken te doen, maar het zit niet in een stabiele versie dus ik ben erg huiverig om dat te gaan gebruiken - nog buiten dat er ook geen documentatie voor geschreven is.

De laatste optie lijkt te zijn FUSE via cygwin te gebruiken. Dit lijkt in mijn ogen de beste optie te zijn, zeker omdat dit ook de mogelijkheid biedt om gewoon op linux te compileren, wat voor mij veel prettiger werkt.

Mis ik hier nog bepaalde zaken, is er een betere optie? Zijn er specifieke pitfalls waar ik rekening mee dien te houden?

Edit: Ik had ergens iets gezien over cygwin en FUSE en daarin ook de lowlevel headers. Ik kan hier nu niet iets zinnigs over terugvinden. Wat ik kan vinden is WinFSP, die weer enkel de high level FUSE api ondersteunt. Ik ben dus nog steeds aan het zoeken naar een geschikte oplossing.

[ Voor 11% gewijzigd door cyberstalker op 20-06-2018 13:13 ]

[MSalters]

Wat precies bedoel je met FUSE? De gebruikelijke interpretatie is Filesystem in User Space, een Linux methode om filesystem code in een userspace library te hebben terwijl je toch het filesystem kunt mounten in de normale filesystem hierarchy (dus onder /). Dit is mogelijk doordat er een enkele generieke "fuse driver" in de kernel bestaat. Daarbovenop heb je libfuse in user space, plus je concrete FUSE implementaties voor verschillende file systemen.

Windows heeft geen fuse driver in de kernel. Dokan is een FUSE-achtige oplossing, met een Windows kernel driver. CBFS lijkt iets vergelijkbaars.

Cygwin lijkt me een red herring. Dat is helemaal geen kernel; Cygwin is een linux-achtige omgeving bovenop de WinNT kernel. Cygwin executables zijn dus echte Win32 PE executables.

[cyberstalker]

Ik bedoel inderdaad "Filesystem in UserSpacE".

Ik heb (zoals ook aangegeven in TS) inderdaad naar zowel dokanym CBFS en cygwin gekeken. Cygwin biedt een translatie van POSIX functionaliteit naar de Windows-API. Daar zijn mensen mee bezig geweest om daarin FUSE beschikbaar te maken. Ik kan alleen niet iets vinden wat echt lijkt te werken.

[__fred__]

Winfsp?

https://github.com/billziss-gh/winfsp

[cyberstalker]

Winfsp zou ik ook naar kunnen kijken. Nadeel daarvan is dat het hele lowlevel gedeelte hiervan ongedocumenteerd is. Enkel de highlevel (en dus blocking) calls zijn gedocumenteerd.

Het lijkt wel het enige project te zijn met een stable release die een asynchroon model ondersteunen.

[MSalters]

"highlevel (en dus blocking)" is natuurlijk een gebrek aan Windows ervaring. De Win32 API heeft oeroude support voor async I/O, al lang voordat het hip was.

[cyberstalker]

@MSalters Ja, ik snap ook niet waarom die support er niet in zit, maar vervelend is het wel. Ik ga maar eens kijken of ik uit die lowlevel api kom.

[MSalters]

@cyberstalker :Die async support hoeft dus niet aanwezig te zijn in alle FUSE-achtige producten die fatsoenlijk Windows-compatible zijn, dwz door normale applicaties gebruikt kunnen worden. Windows zelf zorgt voor de async API.

[cyberstalker]

@MSalters Ik denk dat we een beetje langs elkaar heenpraten. Het gaat mij erom dat de callbacks die ik registreer vanuit mijn applicatie async zijn. Wat het filesystem vervolgens allemaal ondersteunt daar hou ik me niet mee bezig (daarom gebruik ik ook juist zo'n framework).

[MSalters]

De callback die je registreert is een generieke LPOVERLAPPED_COMPLETION_ROUTINE. Je hebt het hele framework niet nodig. Het farmework praat met Windows, Windows praat met jouw applicatie. Er is geen direct contact nodig.

[cyberstalker]

@MSalters Direct contact? Waar heb je het nu over? Ik snap de relevantie niet.

Probeer je nu te zeggen dat ik vanuit mijn applicatie een LPOVERlAPPED_COMPETION_ROUTINE moet registreren die wordt aangeroepen als een gebruiker van het filesystem data wil lezen of een directory wil traversen?

De reden dat ik een framework wil gebruiken is meervoudig, de meest belangrijke is dat als ik het zelf voor elkaar zou krijgen een filesystem driver te maken, ik die gesigned moet krijgen voor alle windows versies en ik dus bij elke update van de app weer door dat hele proces heen moet. Dat op zich lijkt me al enorm veel gedoe.

Daarnaast weet ik nauwelijks iets van Windows omdat ik het eigenlijk nooit gebruik, het is voor mij een enorme kluif om uberhaupt iets te kunnen compileren. Het is voor mij handiger om de documentatie van zo'n framework te lezen, omdat die scope beperkter is.

De functie die jij noemt is bijvoorbeeld alweer deprecated, dus die zou ik niet zomaar gebruiken, want wie weet wordt die straks wel weggehaald. Er staan ook geen voorbeelden bij hoe ik dat moet gebruiken. Ik zou verwachten dat je ergens bij het registreren van je driver een struct met function pointers meegeeft en deze functie daar dan een van is, maar ik word er niet echt wijzer van.

[MSalters]

Oh, je idee is dat je zelf een userspace filesystem wil maken? Je OP had het namelijk over een C++ applicatie. Ik dacht dus dat je een applicatie wilde maken die een bestaande filesystem driver wilde gebruiken.

Anyway, LPOVERLAPPED_COMPETION_ROUTINE is niet deprecated. Het was onderdeel van Windows NT in 1995; het is in 2025 nog steeds onderdeel van whatever Windows je dan hebt. Je hebt er alleen niets aan, want het is hoe Windows applicaties ASIO verzoeken naar de kernel doen.

Die verzoeken komen dan bij de in-kernel filesytem driver aan, die eventueel dus naar Userspace kan springen om het verzoek af te handelen. Die kernel driver moet inderdaad signed zijn. Ik zie dus ook niet in wast cygwin daar gaat doen, die heetf geen signed windows drivers vziw. WinFsp, CBFS en dokany lijken dat wel te hebben.