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

[AlexRMU]

What's up?

[nightlark]

Did you try adding one of the standard options the error message suggested?

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

[AlexRMU]

Oh, sorry, I didn't notice

[AlexRMU]

You can't run this command in the console, I used this: .\tabfs.exe TAGS_MOUNT_DIR="Q:".
If just open tabfs.exe then he writes that he needs libwinpthread-1.dll from mingw-w64\bin and winfsp-x64.dll from WinFsp\bin. Okay I just made a merge of WinFsp and mingw-w64.
Then I executed the command, output:
'{"id": 2, "op": "getattr", "path": "/"}
The disk did not appear, after a while the execution stopped:
[process terminated with code 5]

[AlexRMU]

This is where things currently stop working

As I understand it, nothing is working at the moment? Can @osnr help?

[nightlark]

Depending on if you open it in a MinGW, MSYS, or Windows Command Prompt shell the result may vary slightly, but none of them seem to mount it correctly.

From here I think the thing to do is check if a minimal example using winfsp/fuse works with MinGW. If it doesn't, there are two ways I see to proceed are:

1. Get tabfs.c compiling with MSVC instead. Depending on the POSIX features used, this could be close to a full rewrite.
2. Try cgofuse (made by the maintainer of winfsp) and see if it can mount a drive. May be faster than rewriting for MSVC and easier to build/maintain for Windows support.

[huglovefan]

i've gotten this to work with cygwin in #67 if there's still interest in this

there are build instructions in the pull request for anyone willing to test it

[osnr]

awesome! I will hopefully merge it sometime in the next few days.

I don't have a Windows machine atm -- would be great if someone on here could test it first. @nightlark ?

[nightlark]

I don't have cygwin installed at the moment -- I'll probably have some time to test it early August, and maybe also finish the CI builds.

[osnr]

(do we want to depend on Cygwin? I feel like WSL [or whatever they call it now] is probably ascendant among Windows users?)

[nightlark]

I think it would be preferable not to depend on Cygwin. WSL doesn't support fuse but it looks like winfuse/winfsp may have WSL support -- so that could be easier than trying to replace POSIX calls with the Win32 equivalents (I don't think that would be as much work as I first thought, but still..)