Windows OS support

[bbrendon]

Any hope for the Windows crew?

[jtagcat]

Though it probably doesn't 'just work' (assuming you're not running the browser in WSL), I think you could do something with WSL..?

[minchinweb]

WSL doesn't officially support GUI applications, so you'd first have get your browser up and running in WSL. I've never tried, so I don't know how involved that would be...

[osnr]

maybe with WinFUSE: https://github.com/billziss-gh/winfuse it sounds like this may work with Windows processes too?

or maybe with Dokan FUSE instead of WSL/WinFUSE? https://dokan-dev.github.io/

I don't plan on getting to this myself, but if someone wants to look at it, I'll certainly merge a pull request. My hope is that you could use one of the above and just add another set of cases to the fs Makefile and install.sh and tabfs.c -- like for FreeBSD and it would otherwise just work.

[JinchengWang]

So I just tried this on WSL2.
WSL2 actually supports FUSE natively https://devblogs.microsoft.com/commandline/announcing-wsl-2/
The host binary compiled perfectly too, but accessing mnt just hangs forever. No idea what's going on here...

[osnr]

cool! do you know if the FUSE filesystem gets exposed to Windows applications?

re: the hang, I would look at the browser console for the extension to see if it gets any fs requests and/or try to strace a basic command like ls mnt to see what requests it tries to issue (can you do that on WSL2?)

[JinchengWang]

Concerning whether the FUSE filesystem gets exposed to Windows applications: I have no idea how FUSE or WSL work....
I set this up by making the manifest reference a .bat script which calls wsl which calls bash which calls tabfs which is a linux binary.

The extension says:
Unchecked runtime.lastError: Error when communicating with the native messaging host.
Context
_generated_background_page.html
Stack Trace
_generated_background_page.html:0 (anonymous function)

And this is the strace
strace.txt

[osnr]

update from @nightlark trying MinGW + WinFsp: https://twitter.com/rmast/status/1350344895882412032

[AlexRMU]

@osnr
Can I have instructions for the uninitiated?

[nightlark]

@AlexRMU the rough steps I followed were:

1. Install WinFsp
2. Install mingw-w64 (if not already installed, make sure it has a working copy of gcc).
3. In a MinGW command prompt, run this command to compile the native component of tabfs: gcc tabfs.c -o tabfs.exe -L"C:\Program Files (x86)\WinFsp\lib" -I"C:\Program Files (x86)\WinFsp\inc\fuse" -lwinfsp-x64
4. Run compiled tabfs binary using TABFS_MOUNT_DIR="Q:" ./tabfs.exe (winfsp-x64.dll will need to be in the same folder as the tabfs binary). This is where things currently stop working -- the WinFsp memfs example mounts a drive, whereas running tabfs creates a directory in the current working directory that doesn't seem to be accessible other than from a MinGW shell.

A weird thing with (native) Windows FUSE implementations is that the virtual filesystems get mounted as drive letters rather than folders.

[AlexRMU]

2. What version do I need? Win-Builds?
   http://mingw-w64.org/doku.php/download

[nightlark]

I think the one I have on my system is listed as MingW-W64-builds on that page, but I don't see why Win-Builds wouldn't work to compile tabfs. Will be interesting to see if you get better results with the filesystem mounting correctly.

[AlexRMU]

D:\Desktop\TabFS-win-tabfs\fs\tabfs.c: In function 'tabfs_readdir':
D:\Desktop\TabFS-win-tabfs\fs\tabfs.c:367:5: error: 'for' loop initial declarations are only allowed in C99 mode
     for (int i = 0; json_scanf_array_elem(rdata, rsize, ".entries", i, &t) > 0; i++) {
     ^
D:\Desktop\TabFS-win-tabfs\fs\tabfs.c:367:5: note: use option -std=c99 or -std=gnu99 to compile your code
D:\Desktop\TabFS-win-tabfs\fs\tabfs.c: At top level:
D:\Desktop\TabFS-win-tabfs\fs\tabfs.c:456:5: warning: initialization from incompatible pointer type [enabled by default]
     .getattr  = tabfs_getattr,
     ^
D:\Desktop\TabFS-win-tabfs\fs\tabfs.c:456:5: warning: (near initialization for 'tabfs_oper.getattr') [enabled by default]
D:\Desktop\TabFS-win-tabfs\fs\tabfs.c:460:5: warning: initialization from incompatible pointer type [enabled by default]
     .read    = tabfs_read,
     ^
D:\Desktop\TabFS-win-tabfs\fs\tabfs.c:460:5: warning: (near initialization for 'tabfs_oper.read') [enabled by default]
D:\Desktop\TabFS-win-tabfs\fs\tabfs.c:461:5: warning: initialization from incompatible pointer type [enabled by default]
     .write   = tabfs_write,
     ^
D:\Desktop\TabFS-win-tabfs\fs\tabfs.c:461:5: warning: (near initialization for 'tabfs_oper.write') [enabled by default]
D:\Desktop\TabFS-win-tabfs\fs\tabfs.c:465:5: warning: initialization from incompatible pointer type [enabled by default]
     .readdir    = tabfs_readdir,
     ^
D:\Desktop\TabFS-win-tabfs\fs\tabfs.c:465:5: warning: (near initialization for 'tabfs_oper.readdir') [enabled by default]
D:\Desktop\TabFS-win-tabfs\fs\tabfs.c:468:5: warning: initialization from incompatible pointer type [enabled by default]
     .truncate = tabfs_truncate,
     ^
D:\Desktop\TabFS-win-tabfs\fs\tabfs.c:468:5: warning: (near initialization for 'tabfs_oper.truncate') [enabled by default]
D:\Desktop\TabFS-win-tabfs\fs\tabfs.c:471:5: warning: initialization from incompatible pointer type [enabled by default]
     .mkdir  = tabfs_mkdir,
     ^
D:\Desktop\TabFS-win-tabfs\fs\tabfs.c:471:5: warning: (near initialization for 'tabfs_oper.mkdir') [enabled by default]
D:\Desktop\TabFS-win-tabfs\fs\tabfs.c:472:5: warning: initialization from incompatible pointer type [enabled by default]
     .create = tabfs_create,
     ^
D:\Desktop\TabFS-win-tabfs\fs\tabfs.c:472:5: warning: (near initialization for 'tabfs_oper.create') [enabled by default]

And the file didn't appear

[nightlark]

Try adding the suggested option to the gcc command. Is that using the Win-Builds gcc?

[AlexRMU]

Yes
.\gcc .\TabFS-win-tabfs\fs\tabfs.c -o .\tabfs.exe -L"D:\Program Files (x86)\WinFsp\lib" -I"D:\Program Files (x86)\WinFsp\inc\fuse" -lwinfsp-x64