Fuse Java Binding

[Mitch49]

Hi,

I am trying to integrate jnr-fuse with winfsp. jnr-fuse supports linux but not Windows. I add the fsp_ prefix to all fuse methods and could not run the HelloFuse example. jnr-fuse execute the fuse_main_real method to mount drive. Is there a missing step that needs to be done?

Thanks

Here is the error message:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6f626134, pid=636, tid=0x00001b38
#
# JRE version: Java(TM) SE Runtime Environment (8.0_121-b13) (build 1.8.0_121-b13)
# Java VM: Java HotSpot(TM) Client VM (25.121-b13 mixed mode windows-x86 )
# Problematic frame:
# C  [winfsp-x86.DLL+0x6134]
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# C:\Users\user\AppData\Local\Temp\\hs_err_pid636.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

[billziss-gh]

@Mitch49, thanks for your interest in WinFsp. I will be glad to help as best as I can.

A couple of questions first:

• Is JNR the new JNI or another alternative?

• Do you have your jnr-fuse fork somewhere available for me to try?

I am trying to integrate jnr-fuse with winfsp. jnr-fuse supports linux but not Windows. I add the fsp_ prefix to all fuse methods and could not run the HelloFuse example. jnr-fuse execute the fuse_main_real method to mount drive. Is there a missing step that needs to be done?

The fuse_main_real method should be sufficient to bootstrap a FUSE file system. The real symbol name in WinFsp is fsp_fuse_main_real and takes an additional parameter of type struct fsp_fuse_env * (a WinFsp-FUSE "environment" -- the reason this was done was to support multiple FUSE environments such as the native Windows one, the Cygwin one, etc).

The full prototype for fsp_fuse_main_real is:

FSP_FUSE_API int fsp_fuse_main_real(struct fsp_fuse_env *env,
    int argc, char *argv[],
    const struct fuse_operations *ops, size_t opsize, void *data)

Question: are you properly initializing env (the WinFsp-FUSE "environment")?

# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6f626134, pid=636, tid=0x00001b38
#
# JRE version: Java(TM) SE Runtime Environment (8.0_121-b13) (build 1.8.0_121-b13)
# Java VM: Java HotSpot(TM) Client VM (25.121-b13 mixed mode windows-x86 )
# Problematic frame:
# C  [winfsp-x86.DLL+0x6134]

The EXCEPTION_ACCESS_VIOLATION suggests to me that fsp_fuse_main_real may not be called correctly.

# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# C:\Users\user\AppData\Local\Temp\\hs_err_pid636.log

Do you have the full log mentioned above?

[tstordyallison]

I have a feeling this might be related to #22.

@Mitch49 are you running this via cygwin or just as a normal windows Java process?

[billziss-gh]

@tstordyallison I think you may be right.

Ok, I am now pretty convinced that we need to have fuse_* symbols on top of fsp_fuse_* symbols for non-C derived languages. Did you have any luck on your own work with this? Is it at a state that could be published?

I will look into this after publishing the final WinFsp 2017 (coming this week).

[Mitch49]

Is JNR the new JNI or another alternative?

jnr is an open source library that help to invoke native function without code generation. Annotations are used to map functions and struct. There is also fuse-j which use JNI but its outdated.

You can build and test jnr-fuse without IDE.

git clone https://github.com/Mitch49/jnr-fuse
cd jnr-fuse
gradlew.bat init
gradlew.bat build -x test
java -cp build\libs\jnr-fuse-0.3.1-all.jar ru.serce.jnrfuse.examples.HelloFuse

Here is the full error log: https://gist.github.com/Mitch49/ae5ce5f9061d7a6716ad24d70b65dd79

[Mitch49]

are you running this via cygwin or just as a normal windows Java process?

@tstordyallison just normal Java process without cygwin

[billziss-gh]

You can build and test jnr-fuse without IDE.

@Mitch49 thank you. I will try it and see what I come up with.

[tstordyallison]

I changed the exports on the main winfsp.dll and rebuilt the user space dll and manually used it for my testing. Seemed OK - but I now need to take a proper look at #44 and do some more testing/evangelising to get people behind my use case before doing too much more development...

I think the general plan was create a 'winfuse.dll' that did this rather than the main one (like cygfuse) - but I never got around to looking into it properly.

[billziss-gh]

@Mitch49 I can confirm that this is a problem because fsp_fuse_main_real is not called correctly. Specifically there is no env parameter passed and an access violation happens when the WinFsp-FUSE layer tries to dereference it at this code:

argv = env->memalloc((args->argc + 2) * sizeof(char *));

Here are the values of some of the parameters passed to fsp_fuse_main_real that confirm this (from the Visual Studio Immediate window):

(void *)env
0x0000000000000004
((char **)argc)[0]
0x0000000002580028 "fusefs688640061"
((char **)argc)[1]
0x0000000002580040 "-f"
((char **)argc)[2]
0x0000000002580048 "-d"
((char **)argc)[3]
0x0000000002580050 "C:\\Users\\billziss\\Projects\\ext\\jnr-fuse\\X"
((char **)argc)[4]
0x0000000000000000 <NULL>

The fix is to properly pass the env parameter. I will look into producing a simple jnr-fuse patch for you.

@tstordyallison wrote:

I think the general plan was create a 'winfuse.dll' that did this rather than the main one (like cygfuse) - but I never got around to looking into it properly.

Agreed. I will work on producing a special winfuse.dll in the near future for cases like yours and jnr-fuse as I am now convinced that you were right about this need in the first place :) (issue #22).

[billziss-gh]

The fix is to properly pass the env parameter. I will look into producing a simple jnr-fuse patch for you.

As I am looking more into jnr-fuse this may not be as simple as I originally thought. To see why let's see the definition of fsp_fuse_env:

struct fsp_fuse_env
{
    unsigned environment;
    void *(*memalloc)(size_t);
    void (*memfree)(void *);
    int (*daemonize)(int);
    int (*set_signal_handlers)(void *);
    char *(*conv_to_win_path)(const char *);
    void (*reserved[3])();
};

The fields are:

• environment: this can currently be W for native Windows and C for Cygwin. This is used to control a few things within WinFsp-FUSE: notably whether the long type is 4 bytes or 8 bytes long, and whether errno values and the value of the O_CREAT flag match those of MSVC or Cygwin. Looking at https://github.com/jnr/jnr-constants it seems to me that it should be environment=='W' for jnr-fuse.
• memalloc: this must be the platform malloc. On Windows this may be a wrapper around HeapAlloc, MSVC malloc or something else. On Cygwin it is always the Cygwin malloc. It is unclear what it should be in jnr-fuse. Is there an official malloc for java/jnr apps? [NOTE: this is actually not very important for jnr-fuse, because it only uses fuse_main_real; the FUSE symbols that need to know about the platform "malloc" are some of the fuse_opt_* ones, that are not used directly by jnr-fuse.]
• memfree: see comments above for memalloc.
• daemonize: WinFsp-FUSE supports daemonization when running under Cygwin. I assume this is not required for jnr-fuse running on native Windows. So we need an empty callback for it. I do not know how to create a java callback to be called from C in JNR.
• set_signal_handlers: similar comments to daemonize apply here. Native Windows does not support real POSIX signals, so we just need an empty implementation.
• conv_to_win_path: this is for Cygwin support and can be safely set to 0.

In a nutshell what we need to do is create an fsp_fuse_env object (using JNR Struct?) that we then pass as the first parameter to fsp_fuse_main_real. The object needs to be initialized similar to this (C code):

#define FSP_FUSE_ENV_INIT               \
    {                                   \
        'W',                            \
        malloc, free,                   \
        fsp_fuse_daemonize,             \
        fsp_fuse_set_signal_handlers,   \
        0/*conv_to_win_path*/,          \
    }

static inline int fsp_fuse_daemonize(int foreground)
{
    (void)foreground;
    return 0;
}

static inline int fsp_fuse_set_signal_handlers(void *se)
{
    (void)se;
    return 0;
}

[billziss-gh]

As I am looking more into this, I am thinking that perhaps the best solution is to produce that winfuse.dll that @tstordyallison and I discussed in #22. The DLL would be a simple shim that forwards all requests to fuse_* symbols to the equivalent fsp_fuse_* symbols with a default "environment". This would make projects like fusepy and jnr-fuse that rely on ABI rather than API compatibility to just link to it and work.

One of the main reasons I have been resisting this is the malloc issue that I have discussed above: that there is no well-defined malloc for Windows. For example, malloc in MSVCRT used to be HeapAlloc on a MSVCRT created heap (HeapCreate), it was changed recently to be HeapAlloc on the default heap (GetProcessHeap). On debug builds malloc adds a preamble and postamble primarily to catch buffer overruns/underruns I think. And who knows what malloc does in other compilers or old versions of MSVC.

So we have multiple options here:

1. Leave things as they are. Projects that want to interface with WinFsp and use native C/C++ to do so, just work (e.g. node.js fuse-bindings). Projects that use alternative mechanisms like FFI (fusepy, jnr-fuse) have to go through the pain of somehow implementing a default env to give to fsp_fuse_* methods.

2. Implement multiple winfuse.dll's, one each for every mainstream malloc there is. This would mean debug/release versions for the old MSVCRT, debug/release versions for the new MSVCRT, etc. Nightmarish.

3. Create a winfuse.dll that somehow autodetects the correct malloc. This sounds convenient, and it would be great if it worked, but I suspect that it would become an endless source of headaches for whoever maintains it. [And what if a program used 2 different malloc's? Although not ideal, it is not unheard of in Windows.]

4. Implement one true winfuse.dll that implements malloc(size) as HeapAlloc(GetProcessHeap(), 0, size). While this will not work in all cases, I suspect that it will work on many, because many projects that use FFI also simply use fuse_main_real and do not use directly any of the symbols that require the FUSE layer malloc and the main program's malloc to be the same (e.g. fuse_opt_parse). This is true for jnr-fuse and fusepy, for example.

I am leaning towards (4). Thoughts?

[tstordyallison]

I would happy with 4).

For those who want something more exotic for debugging etc, they can build the userspace dll from source (we might want to make that easier so it doesn't need the DDK etc, but it isn't all that bad in honesty).

If a genuine need comes up for a different build, we can address it then.

[ghost]

The fourth solution seems to be the best. If someone wants more customization he can write modified version of fuse_main_real.

[billziss-gh]

In the end I chose the path of least resistance and added the fuse_* symbols to the WinFsp DLL (winfsp-x64.dll, winfsp-x86.dll). Adding a new winfuse.dll would probably increase confusion for users. It would also require me to change the WinFsp installer and the FLOSS exception to the license.

These new symbols are not supposed to be used by native C/C++ programs. Such programs are supposed to include the <fuse.h> headers, which expose the fuse_* symbols as static inline functions that reference the fsp_fuse_* symbols. This way the proper "environment" (malloc, etc.) is picked up automatically.

The symbols are currently added to the import libraries (winfsp-x64.lib, winfsp-x86.lib). I would rather they did not, but I do not know of any obvious way to exclude them. [Please let me know if you do; I do not want programs to link with these symbols accidentally to avoid the caveats we discussed.]

These symbols are for use with programs that use FFI technology such as jnr-fuse and fusepy ONLY.

Commit db05667 includes these changes and is currently being tested although it passed my local smoke testing.

With this commit and the patch below I am able to start jnr-fuse without access violations.

diff --git a/src/main/java/ru/serce/jnrfuse/AbstractFuseFS.java b/src/main/java/ru/serce/jnrfuse/AbstractFuseFS.java
index 9600bf3..7947bc0 100755
--- a/src/main/java/ru/serce/jnrfuse/AbstractFuseFS.java
+++ b/src/main/java/ru/serce/jnrfuse/AbstractFuseFS.java
@@ -47,7 +47,8 @@ public abstract class AbstractFuseFS implements FuseFS {

     public AbstractFuseFS() {
         LibraryLoader<LibFuse> loader = LibraryLoader.create(LibFuse.class);
-        libFuse = loader.load("C:\\Program Files (x86)\\WinFsp\\bin\\winfsp-x86.dll");
+        //libFuse = loader.load("C:\\Program Files (x86)\\WinFsp\\bin\\winfsp-x64.dll");
+        libFuse = loader.load("winfsp-x64.dll");

         Runtime runtime = Runtime.getSystemRuntime();
         fuseOperations = new FuseOperations(runtime);
@@ -251,7 +252,7 @@ public abstract class AbstractFuseFS implements FuseFS {
     }

     private int execMount(String[] arg) {
-        return libFuse.fsp_fuse_main_real(arg.length, arg, fuseOperations, Struct.size(fuseOperations), null);
+        return libFuse.fuse_main_real(arg.length, arg, fuseOperations, Struct.size(fuseOperations), null);
     }

     @Override
diff --git a/src/main/java/ru/serce/jnrfuse/LibFuse.java b/src/main/java/ru/serce/jnrfuse/LibFuse.java
index e99ea9d..8cb830d 100755
--- a/src/main/java/ru/serce/jnrfuse/LibFuse.java
+++ b/src/main/java/ru/serce/jnrfuse/LibFuse.java
@@ -44,5 +44,5 @@ public interface LibFuse {
      * @param user_data user data supplied in the context during the init() method
      * @return 0 on success, nonzero on failure
      */
-    int fsp_fuse_main_real(int argc, String[] argv, FuseOperations op, int op_size, Pointer user_data);
+    int fuse_main_real(int argc, String[] argv, FuseOperations op, int op_size, Pointer user_data);
 }
diff --git a/src/main/java/ru/serce/jnrfuse/examples/HelloFuse.java b/src/main/java/ru/serce/jnrfuse/examples/HelloFuse.java
index 1457d29..80190a1 100755
--- a/src/main/java/ru/serce/jnrfuse/examples/HelloFuse.java
+++ b/src/main/java/ru/serce/jnrfuse/examples/HelloFuse.java
@@ -80,7 +80,7 @@ public class HelloFuse extends FuseStubFS {
     public static void main(String[] args) {
         HelloFuse stub = new HelloFuse();
         try {
-            stub.mount(Paths.get("X:"), true, true);
+            stub.mount(Paths.get("X"), true, true);
         } finally {
             stub.umount();
         }

However the file system does not currently work as it keeps returning ENOENT from getattr. Here is an example log:

The service java has been started.
java[TID=0cd8]: FFFF9A0C4FC3C410: >>QueryVolumeInformation
java[TID=0cd8]: FFFF9A0C4FC3C410: <<QueryVolumeInformation IoStatus=0[0] VolumeInfo={TotalSize=0:0, FreeSize=0:0, VolumeLabel=""}
java[TID=0cd8]: FFFF9A0C4C6134A0: >>Create [UT---C] "\", FILE_OPEN, CreateOptions=20, FileAttributes=0, Security=NULL, AllocationSize=0:0, AccessToken=00000000000003A4, DesiredAccess=100080, GrantedAccess=0, ShareAccess=7
java[TID=0cd8]: FFFF9A0C4C6134A0: <<Create IoStatus=c0000034[0]
java[TID=0cd8]: FFFF9A0C4C6134A0: >>Create [UT---C] "\", FILE_OPEN, CreateOptions=21, FileAttributes=10, Security=NULL, AllocationSize=0:0, AccessToken=00000000000003A4, DesiredAccess=100001, GrantedAccess=0, ShareAccess=7
java[TID=0cd8]: FFFF9A0C4C6134A0: <<Create IoStatus=c0000034[0]
java[TID=0cd8]: FFFF9A0C4E0F5680: >>Create [UT---C] "\", FILE_OPEN, CreateOptions=20, FileAttributes=0, Security=NULL, AllocationSize=0:0, AccessToken=00000000000003E8, DesiredAccess=100081, GrantedAccess=0, ShareAccess=7
java[TID=0cd8]: FFFF9A0C4E0F5680: <<Create IoStatus=c0000034[0]
java[TID=1744]: FFFF9A0C4E0F5680: >>Create [UT---C] "\", FILE_OPEN, CreateOptions=21, FileAttributes=10, Security=NULL, AllocationSize=0:0, AccessToken=00000000000003E8, DesiredAccess=100001, GrantedAccess=0, ShareAccess=7
java[TID=1744]: FFFF9A0C4E0F5680: <<Create IoStatus=c0000022[0]
java[TID=1744]: FFFF9A0C49BC0480: >>Create [UT---C] "\", FILE_OPEN, CreateOptions=20, FileAttributes=0, Security=NULL, AllocationSize=0:0, AccessToken=00000000000003E8, DesiredAccess=100081, GrantedAccess=0, ShareAccess=7
java[TID=1744]: FFFF9A0C49BC0480: <<Create IoStatus=c0000034[0]
java[TID=0cd8]: FFFF9A0C49BC0480: >>Create [UT---C] "\", FILE_OPEN, CreateOptions=21, FileAttributes=10, Security=NULL, AllocationSize=0:0, AccessToken=00000000000003E8, DesiredAccess=100001, GrantedAccess=0, ShareAccess=7
java[TID=0cd8]: FFFF9A0C49BC0480: <<Create IoStatus=c0000034[0]

The IoStatus=c0000034 is STATUS_OBJECT_NAME_NOT_FOUND which is the NTSTATUS code for ENOENT. I have not had the time to figure out why HelloFuse does that. The problem happens when it is run in either single-threaded or multi-threaded mode.

[Mitch49]

This is great. Now It will be easier to integrate fuse libraries with winfsp. It seems that jnr-fuse will require additional improvement and bugfixes. I will debug the HelloFuse after the stable version is released.

Thanks

[billziss-gh]

This is great. Now It will be easier to integrate fuse libraries with winfsp. It seems that jnr-fuse will require additional improvement and bugfixes. I will debug the HelloFuse after the stable version is released.

Thanks

You are welcome!

BTW, I added some simple logging in the HelloFuse getattr method and I am finding out that the path gets garbled:

**** getattr "/"
The service java has been started.
java[TID=17d4]: FFFF9A0C4C6BE2E0: >>QueryVolumeInformation
java[TID=17d4]: FFFF9A0C4C6BE2E0: <<QueryVolumeInformation IoStatus=0[0] VolumeInfo={TotalSize=0:0, FreeSize=0:0, VolumeLabel=""}
java[TID=17d4]: FFFF9A0C4DEDEC80: >>Create [UT---C] "\", FILE_OPEN, CreateOptions=20, FileAttributes=0, Security=NULL, AllocationSize=0:0, AccessToken=000000000000038C, DesiredAccess=100080, GrantedAccess=0, ShareAccess=7
**** getattr "/  �? � ?YÅú � ?   �? ƒ ?Y?úi� ?-d �? � ?Y?úA� ?   �? ƒ ?Y?úR� ? ¿°"
java[TID=17d4]: FFFF9A0C4DEDEC80: <<Create IoStatus=c0000034[0]
java[TID=17d4]: FFFF9A0C4A7F64A0: >>Create [UT---C] "\", FILE_OPEN, CreateOptions=21, FileAttributes=10, Security=NULL, AllocationSize=0:0, AccessToken=000000000000038C, DesiredAccess=100001, GrantedAccess=0, ShareAccess=7
**** getattr "/  �? ƒ £Y?ú\� ?   �? � ¢Y?ú-� ?   �? ƒ ?Y?ú3� ?/  �? � ¬Y?ú2� ?-d �? ƒ ?Y?ú9� ?   �? � ?Y?ú8 ?/  �? ƒ ?Y?ú ?java"
java[TID=17d4]: FFFF9A0C4A7F64A0: <<Create IoStatus=c0000034[0]

[billziss-gh]

WinFsp 2017 is out 🎉

Get it here: https://github.com/billziss-gh/winfsp/releases/tag/v1.0

It has the new fuse_* symbols discussed in this thread. Let me know if you have any problems as this was a last minute change.

[SerCeMan]

This issue seems really great! 👍 I'm not quite familiar with winfsp project but it looks amazing!

I think garbled paths is a consequence of inconsistency between alignments/field offsets in structs and actual platform implementation. I would expect some differences there. Using JNR requires defining all the offsets for each field because from Java's point of view it has only some pointer and you need to know the offset for each field in order to access it. It's not a problem for most cases, but even one wrong offset for a field in the beginning, can lead to corruption of the whole structure.

The first step might be to run this test StructSizeTest.java. The fact that this test passes. This test doesn't tell much, but might point to some obvious inconsistencies (the test includes expected sizes for all structures on Linux x64/x32).

The second step might be a bit trickier, it contains a few steps:

• write a small C program that prints sizes of each structure printed
• compare the size of each structure with the value defined in test
• For found inconsistencies, find wrong offsets by removing fields from the end one by one and comparing offsets to what defined in java.
• Each wrong offset can be fixed either by some general type from JNR (if exists) or a conditional assignment Field attr = Platform.IS_WIN ? ... : ...

[billziss-gh]

@SerCeMan thanks for stopping by!

I think garbled paths is a consequence of inconsistency between alignments/field offsets in structs and actual platform implementation. I would expect some differences there. Using JNR requires defining all the offsets for each field because from Java's point of view it has only some pointer and you need to know the offset for each field in order to access it. It's not a problem for most cases, but even one wrong offset for a field in the beginning, can lead to corruption of the whole structure.

Your comments make a lot of sense.

I list here some general ideas as well as issues that came up when I was porting FUSEPY to native Windows and Cygwin (fusepy fork). I suspect that some of these may apply to a jnr-fuse port:

• Windows either lacks of has limited versions of many of the POSIX structs such as struct stat and struct statvfs. For this reason WinFsp-FUSE defines its own struct fuse_stat and struct fuse_statvfs.
• The WinFsp-FUSE layer attempts to support both native Windows and Cygwin with a single API. To achieve this all WinFsp-FUSE structs are compatible with the Cygwin ones. For example, the WinFsp struct fuse_stat is compatible with Cygwin's struct stat.
• Jnr-fuse defines its own structs in ru.serce.jnrfuse.struct. For example, FileStat and Statvfs would have to be changed to conform with the definitions in winfsp_fuse.h. Some of these definitions also differ between Win32 and Win64.
• sizeof(long)==4 in Win32 and Win64. This is different from Linux where it is 4 for 32-bit and 8 for 64-bit. [BTW, 64-bit Cygwin on Windows uses 8-byte long's like Linux.]

[ghost]

I could mount winfsp from Java with fuse-jna with these commits. Both HelloFS and MemoryFS run without error. Somehow Linux x86-64 alignments work for Windows environment without modification.

When i am trying to test HelloFS, winfsp allow me to use seperator character / in file names. As far as i know both Windows & Linux file systems do not allow to use seperator character in file names. Is this is a bug?

Test environment: Win10, 32-bit Java 8

[billziss-gh]

@ui4j fanastic work! Trying it now.

EDIT: any quick instructions to build / run this? Will save me the googling :)

[ghost]

git clone https://github.com/ui4j/fuse-jna.git
cd fuse-jna
gradlew.bat build -x test
gradlew.bat uberJar
copy "c:\Program Files (x86)\WinFsp\bin\*.dll" .
java -cp build\libs\fuse-jna-1.0.3-uber.jar net.fusejna.examples.HelloFS
cd X:

java -cp build\libs\fuse-jna-1.0.3-uber.jar net.fusejna.examples.MemoryFS
cd X:

[billziss-gh]

@ui4j this works very well. Thank you!

When i am trying to test HelloFS, winfsp allow me to use seperator character / in file names. As far as i know both Windows & Linux file systems do not allow to use seperator character in file names. Is this is a bug?

I am not sure I completely understand what you mean. Can you give me an example? I tried using the / character on both HelloFs and MemoryFs and was not able to.

[billziss-gh]

BTW, you can get information about the WinFsp installation directory from the registry (HKLM\Software\WinFsp\InstallDir in the 32-bit part of the registry).

Here is how this is done in C code (notice the KEY_WOW64_32KEY flag):

https://github.com/billziss-gh/winfsp/blob/master/inc/winfsp/winfsp.h#L1639

[gsaxena888]

I'm a little confused. Do we have a working version that uses fuse-jnr instead of fuse-jna? (From what I understand, the jna version will be much much slower, but I could be wrong.) If we do have a working version of fuse-jnr that talks to winfsp, is there a simple example code (eg passthrough or memFS) that uses Java (and specifically fuse-jnr) you could point us to so that we could use as a starting point? That would be super super super cool.....

[billziss-gh]

@gsaxena888

Do we have a working version that uses fuse-jnr instead of fuse-jna?

Not to my knowledge. I know @Mitch49 was working on it, but I do not know whether a working version exists.

It also looks like @ui4j is no longer around, so there is currently no fuse-jna port either.

[gsaxena888]

@billziss-gh Just FYI: I requested the owner of jnr-fuse, @SerCeMan , to help and he made (huge?) progress towards getting jnr-fuse to work with winfsp. Please see the last few comments here: SerCeMan/jnr-fuse#16 (comment)

So, jnr-fuse's helloWorld program works with winfsp now. However, the MemoryFS does not....I tried to take a look, but it's beyond my ability to understand where the problem may be, and @SerCeMan thinks it might require more expertise with Windows or WinFSP....any chance you might be able to take a look now that the HelloWolrd jnr-fuse program is working with winfsp (but the MemoryFS is not)?

[billziss-gh]

@gsaxena888 I will have a look. Thanks for the pointer.

[nkataieva]

@billziss-gh I think this question is for the same thread - we are testing jnr-fuse and having problem with writing files on mounted disk. Seems like problem is in calls to Winfsp (see last two comments here: SerCeMan/jnr-fuse#16 (comment)) Could you please take a look if possible? I will try to provide more detailed stacktrace as soon as possible.

[billziss-gh]

Closing this issue as jnr-fuse now has support for Windows and WinFsp.