search

SerCeMan / jnr-fuse

FUSE implementation in Java using Java Native Runtime (JNR)
MIT License
365 stars 87 forks source link

Fuse specific objects are missing the correct .toString() implementation #42

Open stanimirivanovde opened 6 years ago

stanimirivanovde commented 6 years ago

I kept having random segfaults on Windows (through WinFSP) because the FileInfo structure was not correctly transformed during a debug call. I think all user provided objects should properly implement the toString() function in a safe way. The way I worked around it is to provide my own getString() set of functions for each Fuse object such as FileInfo, FileStat, Timespec etc. I didn't have this problem on osxfuse. So it might be platform specific.

stanimirivanovde commented 6 years ago

Currently I get segfaults in WinFSP if I try to place a breakpoint in getattr(). I think this happens due to Intellij's attempt to show the variables in the debugger which calls FileStat's stat.toString() method. I am not sure if this is only me, but I can't seem to explain why placing a breakpoint in the function would cause WinFSP to segfault when stepping through it, but if I don't place a breakpoint then no issues will be seen.

The problem I am trying to debug is that when the mount drive in Windows is empty (say T: ) then trying to list the files in the mount directory results in NoSuchFileException. While if the mount directory has one or more files/dirs then the list succeeds. I don't see this issue on Mac OS X so I am trying to see if there is something in my readdir implementation that is wrong. But I have a pretty simple readdir implementation so I can't seem to figure out why Java fails.

There are a couple of inconsistencies in Java methods when it comes to working with directories on Windows.

First, sometimes Path myPath.toFile().isDirectory() might return false when the path is the mount directory (T:)

Second the call Files.list( path ) will return NoSuchFileException when the path is the mount directory (T:) and it is empty.

Third the call path.toFile().list() might return null in some cases (I've seen it once or twice to return this) which aligns to what I observe from Files.list( path ). But most of the time path.toFile().list().length succeeds in returning 0 elements and giving me what I want for the mount path (T:) when it is empty. So substituting all my calls from Files.list( path ).count() to path.toFile().list().length() fixes my unit tests failing. But it is weird that the one function will fail while the other will succeed.

Another inconsistency is having to create directories: Files.createDirectories() fails all the time on Windows, while newDirectoryPath.toFile().mkdirs() succeeds with no problem when trying to create nested directories on the mounted path: T:/first/second/third/fourth/.

Do you happen to know why some of the functions will succeed while the others will fail?

SerCeMan commented 6 years ago

Hi, @stanimirivanovde!

I haven't encountered breakpoint problems before, but I haven't done much development for Win, so I assume there are might be issues with how IJ explores objects. I agree that toString() should not fail, so I'm happy to accept a PR that fixes this (if adding proper toStrings helps).

Do you happen to know why some of the functions will succeed while the others will fail?

I don't know, but I guess that it can be discovered from the debug logs. If the actual underlying calls misbehave, then it's worth asking for advice on the winfsp repo.