TabFS
TabFS copied to clipboard
osnr
Windows OS support
Though it probably doesn't 'just work' (assuming you're not running the browser in WSL), I think you could do something with WSL..?
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...
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.
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...
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?)
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
update from @nightlark trying MinGW + WinFsp: https://twitter.com/rmast/status/1350344895882412032
@AlexRMU the rough steps I followed were:
- Install WinFsp
- Install mingw-w64 (if not already installed, make sure it has a working copy of gcc).
- 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 - 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.
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.
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
Try adding the suggested option to the gcc command. Is that using the Win-Builds gcc?
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
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
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]
This is where things currently stop working
As I understand it, nothing is working at the moment? Can @osnr help?
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:
- Get tabfs.c compiling with MSVC instead. Depending on the POSIX features used, this could be close to a full rewrite.
- 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.
i've gotten this to work with cygwin in https://github.com/osnr/TabFS/pull/67 if there's still interest in this
there are build instructions in the pull request for anyone willing to test it
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 ?
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.
(do we want to depend on Cygwin? I feel like WSL [or whatever they call it now] is probably ascendant among Windows users?)
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..)