Search for lib in java.library.path instead of hardcoded path

[nicomem]

Resolve #72

[CLAassistant]

All committers have signed the CLA.

[overheadhunter]

Both System.mapLibraryName and looking in java.library.path is what Java does per default (via System.loadLibrary), however what happens here is that it simply adds "lib" + name + ".so" on Linux, which fails if the file name is e.g. Debian's libfuse3.so.3.

Hence we had to ditch this default approach.

What we discussed internally: Adding a separate system property, however some Cryptomator distributions (like the AppImage) don't allow to manually override those. Our best option currently is to look in some well-known locations and fallback to System.loadLibrary and hope that there is no additional suffix after .so.

[infeo]

fallback to System.loadLibrary and hope that there is no additional suffix after .so.

Some systems create a symlink to the newest version of a library, some not. If we add this last ditch attempt, we need to ensure to use the correct fuse version (by calling fuse_version())

[overheadhunter]

fallback to System.loadLibrary and hope that there is no additional suffix after .so.

Some systems create a symlink to the newest version of a library, some not. If we add this last ditch attempt, we need to ensure to use the correct fuse version (by calling fuse_version())

The major version (which ensures API-compatibility) is part of the lib name (fuse3 instead of fuse)

[overheadhunter]

I just opened cryptomator/jfuse#37 to fallback to the System.loadLibrary mechanism.

fuse-nio-adapter should not duplicate what Java is already doing. Instead builder.setLibraryPath(...) is intended to be used to attempt loading from a verified path to an existing .so file.

If no such file could be found in those places, do not set the library path, which will then cause jfuse to fallback to System.loadLibrary(...).

In other words: After updating jfuse, we need something like this:

Arrays.stream(LIB_PATHS).map(Path::of).filter(Files::exists).map(Path::toString).findAny().ifPresent(builder::setLibraryPath);

[nicomem]

Since there will now be a fallback mecanism in case no element in LIB_PATHS is present, the isSupported() method will also need to remove the first test and simply become return isFusermount3Installed();, right?

[overheadhunter]

Since there will now be a fallback mecanism in case no element in LIB_PATHS is present, the isSupported() method will also need to remove the first test and simply become return isFusermount3Installed();, right?

Right!

Furthermore we need to remove /ust/lib/libfuse3.so from our array, as this is now handled via the fallback mechanism (assuming /usr/lib is in java.library.path on any sane system). Otherwise it would take precedence over e.g. /usr/lib64, which is what causes cryptomator/cryptomator#3127.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[overheadhunter]

Thank you @nicomem 🙌