richardsimko
commented
4 years ago Reverting to 1.26.0 solves the issue even with the latest osxfuse so it seems to be an issue with rar2fs
Closed richardsimko closed 4 years ago
richardsimko
commented
4 years ago Reverting to 1.26.0 solves the issue even with the latest osxfuse so it seems to be an issue with rar2fs
hasse69
commented
4 years ago Thanks for the issue report. Unfortunately I have very limited possibilities to try this myself and last time I checked rar2fs worked fine on OS X. The delta between latest release (1.29.0) and 1.26.0 is huge. I think you need to narrow it down somewhat to tell in what exact version things started to fail for you.
hasse69
commented
4 years ago Also note that 1.26.0 does not link statically to libunrar which suggest you probably linked to some old version unless you rebuilt libunrar and completely re-installed it. Standing in the repo/source root folder simply doing
ldd src/rar2fsor
src/rar2fs --versionwould probably tell
Note that in latest version of rar2fs the source tree has been completely re-structured. The compiled binary is nowadays located in the src folder.
EDIT: I think we need to make sure that the problems you are experiencing is not related to some bad build and/or combination of rar2fs and libunrar. Please make sure that if you also change to latest version of libunrar that you make a proper clean of the rar2fs build and then re-build. Also make sure to build libunrar first e.g.
# cd unrar
# make lib
# cd ..
# make clean
# ./configure
# makeI rebuilt libunrar for both the installs, as per the install instructions. With 1.29.0 I used 5.9.2 (Which is the latest one) and with 1.26.0 I used 5.4.5 as 5.9.2 was not compatible. For now those are the only two combinations I've tried.
I'm happy to test other combinations for you if you know which ones are worth trying, or versions of rar2fs between 1.26.0 and 1.29.0 if you would like. :)
richardsimko
commented
4 years ago Trying to build 1.29.0 against 5.4.5 of libunrar yields the following error, not sure if it's helpful:
mv -f .deps/rar2fs.Tpo .deps/rar2fs.Po
g++ -o rar2fs dllext.o optdb.o filecache.o iobuffer.o sighandler.o hashtable.o dircache.o dirlist.o rarconfig.o dirname.o rar2fs.o -D_THREAD_SAFE -pthread -rdynamic -lfuse /Users/user/Downloads/rar2fs-1.29.0/unrar/libunrar.a -liconv -ldl
Undefined symbols for architecture x86_64:
"RarTime::GetRaw()", referenced from:
_RARListArchiveEx in dllext.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [rar2fs] Error 1
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1Ok, if you are sure you have built everything properly then I guess it is not very likely to be a user error. Make sure that when using later version of libunrar that you link statically (which is the default if ./configure can locate libunrar.a). You can double check if it linked statically by using ldd on the compiled rar2fs binary. Again, I have had no recent reports of rar2fs not working on OS X and last time I checked it worked fine. I cannot tell exactly what version that was used back then but it was definitely while working with issue #119 so for sure something later than 1.26.0.
I would try all versions one by one from 1.26.0 to 1.29.0.
hasse69
commented
4 years ago Trying to build 1.29.0 against 5.4.5 of libunrar yields the following error, not sure if it's helpful:
mv -f .deps/rar2fs.Tpo .deps/rar2fs.Po g++ -o rar2fs dllext.o optdb.o filecache.o iobuffer.o sighandler.o hashtable.o dircache.o dirlist.o rarconfig.o dirname.o rar2fs.o -D_THREAD_SAFE -pthread -rdynamic -lfuse /Users/user/Downloads/rar2fs-1.29.0/unrar/libunrar.a -liconv -ldl Undefined symbols for architecture x86_64: "RarTime::GetRaw()", referenced from: _RARListArchiveEx in dllext.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [rar2fs] Error 1 make[1]: *** [all] Error 2 make: *** [all-recursive] Error 1
I will need to check this one. We are supposed to support most pre-historic versions of libunrar.
EDIT: Ok, checked this one and yes, I see the same problem on Linux. I have no clue to why we see this though because all the symbols are there in the .so file :(
richardsimko
commented
4 years ago FYI macOS doesn't have ldd but according to Google the equivalent is otool -L which when I run it on src/rar2fs in version 1.29.0 I get the following output:
src/rar2fs:
/usr/local/lib/libfuse.2.dylib (compatibility version 10.0.0, current version 10.5.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)And on the 1.26.0 I see:
rar2fs:
/usr/local/lib/libfuse_ino64.2.dylib (compatibility version 10.0.0, current version 10.5.0)
libunrar.so (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)So there's definitely a difference there, not sure if it's a hint to anything though.
richardsimko
commented
4 years ago I tried 1.27.0, 1.27.2, and 1.28.0, all of them with ~5.4.5~ 5.9.2 of libunrar. It seems to break at 1.28.0, prior versions work. They all have the same output from otool -L as 1.29.0 though.
hasse69
commented
4 years ago I still suspect there is something weird going on here with your build and that there is a version mismatch with what you build and link against, which must be of the same version. I found the root cause of the failed symbol lookup, and it was caused by a bug in configure.ac that did not consider that source code is now built from the src folder. That made linking pick the wrong library from my system path rather then the one I just built in my local unrar folder.
See https://github.com/hasse69/rar2fs/commit/1401cf093baa289b334230d829688d00630c078c
hasse69
commented
4 years ago It is not possible that otool gives you the same output as 1.29.0 for any version of rar2fs built against libunrar 5.4.5 because of the simple reason that version does not create a static library. So please try to avoid using 5.4.5 completely and use something more recent and then try 1.28.0 again.
richardsimko
commented
4 years ago Sorry, I mistyped! I used libunrar 5.9.2 in all cases above!
hasse69
commented
4 years ago This is however a bit weird
/usr/local/lib/libfuse.2.dylib (compatibility version 10.0.0, current version 10.5.0)
vs
/usr/local/lib/libfuse_ino64.2.dylib (compatibility version 10.0.0, current version 10.5.0)Are these really the same files? I do not think so. And why is it picking a different file for 1.26,0? Is OSXFUSE really providing both of these libraries? I wonder if the library search order that I changed some time back is related. Perhaps that was done starting from 1.28.0. Can you check what version of fuse is picked for 1.27.0 and 1.27.2 please.
richardsimko
commented
4 years ago 1.27.0:
rar2fs:
/usr/local/lib/libfuse_ino64.2.dylib (compatibility version 10.0.0, current version 10.5.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)1.27.2:
rar2fs:
/usr/local/lib/libfuse_ino64.2.dylib (compatibility version 10.0.0, current version 10.5.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)1.28.0:
src/rar2fs:
/usr/local/lib/libfuse.2.dylib (compatibility version 10.0.0, current version 10.5.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)Something definitely changed there with 1.28.0!
hasse69
commented
4 years ago Great! Ok, then I think we might have found the issue. I am still a bit confused though to why this has never been spotted before. Most likely it is your architecture that is very different from what I have been able to test on. Let's see if it is as simple as this.
In the configure.ac file you should be able to find a few lines looking like this
AC_CHECK_LIB(fuse,fuse_new, [FUSE_LIBS="-lfuse"],
[ AC_CHECK_LIB(dokanfuse1.dll,fuse_new, [FUSE_LIBS="-ldokanfuse1.dll"],
[ AC_CHECK_LIB(osxfuse,fuse_new, [FUSE_LIBS="-losxfuse"],
[ AC_CHECK_LIB(fuse4x,fuse_new, [FUSE_LIBS="-lfuse4x"],
[ AC_CHECK_LIB(fuse_ino64,fuse_new, [FUSE_LIBS="-lfuse_ino64"],Now change these too
AC_CHECK_LIB(fuse_ino64,fuse_new, [FUSE_LIBS="-lfuse_ino64"],
[ AC_CHECK_LIB(dokanfuse1.dll,fuse_new, [FUSE_LIBS="-ldokanfuse1.dll"],
[ AC_CHECK_LIB(osxfuse,fuse_new, [FUSE_LIBS="-losxfuse"],
[ AC_CHECK_LIB(fuse4x,fuse_new, [FUSE_LIBS="-lfuse4x"],
[ AC_CHECK_LIB(fuse,fuse_new, [FUSE_LIBS="-lfuse"],Basically swapping search for libfuse_ino64 with libfuse.
After the change, re-run configure and make sure it finds the proper library, e.g.
checking for fuse_new in -lfuse_ino64... yesYou should not see something like
checking for fuse_new in -lfuse... yesThat did the trick! Now 1.29.0 works! Thanks for the stellar help! And thanks for a great piece of software, it's served me well for many years now 🎉
As a side note, I experimented a bit with fuse as well and realized that the MacFUSE compatibility layer must be installed in order for rar2fs to work, otherwise it fails when looking for fuse.h. That might be worth mentioning in the install instructions :)
hasse69
commented
4 years ago Are you sure about that? I was under the impression that the MacFUSE compatibility layer was only there to provide support for some very ancients systems? So you are saying that OSXFUSE does not install the header files? That seems a bit odd to be honest or OSXFUSE does not by default support target development but only run-time in that case.
I will think about how to solve your issue in a proper patch, probably as simple as doing what we just did. But I need a couple of iterations in my head before I can tell for sure.
richardsimko
commented
4 years ago If I run it without that installed I get the following output from ./configure:
checking fuse.h usability... no
checking fuse.h presence... no
checking for fuse.h... no
configure: error:
Cannot find fuse.h - add alternative include search path using
--with-fuse and rerun configure.I also only have the following fuse libs:
-rwxr-xr-x 1 root wheel 951K 5 Dec 13:32 libosxfuse.2.dylib
lrwxr-xr-x 1 root wheel 18B 13 Apr 22:06 libosxfuse.dylib -> libosxfuse.2.dylib
-rwxr-xr-x 1 root wheel 933B 5 Dec 13:32 libosxfuse.la
lrwxr-xr-x 1 root wheel 18B 13 Apr 22:06 libosxfuse_i64.2.dylib -> libosxfuse.2.dylib
lrwxr-xr-x 1 root wheel 16B 13 Apr 22:06 libosxfuse_i64.dylib -> libosxfuse.dylib
lrwxr-xr-x 1 root wheel 13B 13 Apr 22:06 libosxfuse_i64.la -> libosxfuse.laWith compatibility installed I get these:
lrwxr-xr-x 1 root wheel 13B 13 Apr 22:11 libfuse.0.dylib -> libfuse.dylib
-rwxr-xr-x 1 root wheel 615K 5 Dec 13:33 libfuse.2.dylib
lrwxr-xr-x 1 root wheel 15B 13 Apr 22:11 libfuse.dylib -> libfuse.2.dylib
-rwxr-xr-x 1 root wheel 917B 5 Dec 13:33 libfuse.la
-rwxr-xr-x 1 root wheel 615K 5 Dec 13:33 libfuse_ino64.2.dylib
lrwxr-xr-x 1 root wheel 21B 13 Apr 22:11 libfuse_ino64.dylib -> libfuse_ino64.2.dylib
-rwxr-xr-x 1 root wheel 947B 5 Dec 13:33 libfuse_ino64.la
-rwxr-xr-x 1 root wheel 951K 5 Dec 13:32 libosxfuse.2.dylib
lrwxr-xr-x 1 root wheel 18B 13 Apr 22:11 libosxfuse.dylib -> libosxfuse.2.dylib
-rwxr-xr-x 1 root wheel 933B 5 Dec 13:32 libosxfuse.la
lrwxr-xr-x 1 root wheel 18B 13 Apr 22:11 libosxfuse_i64.2.dylib -> libosxfuse.2.dylib
lrwxr-xr-x 1 root wheel 16B 13 Apr 22:11 libosxfuse_i64.dylib -> libosxfuse.dylib
lrwxr-xr-x 1 root wheel 13B 13 Apr 22:11 libosxfuse_i64.la -> libosxfuse.laSo without compatibility the libfuse_ino64.2.dylib is missing.
hasse69
commented
4 years ago Interesting, but I think what you really should use here is libosxfuse_i64? Last time I checked with OSXFUSE people the compatibility layer should normally not be used. And rar2fs obviously is lagging behind the OSXFUSE development since the _i64 variant is not part of the list configure is searching for :(
richardsimko
commented
4 years ago I'm not the one selecting ;)
But it seems strange to me as well that it doesn't work, since libosxfuse is in the list that it's searching for? I'm presuming it's this line?
[ AC_CHECK_LIB(osxfuse,fuse_new, [FUSE_LIBS="-losxfuse"],Yea, but it is an exclusive search order, right? So if it finds something before that line it will pick that one instead.
Can you play a little bit with this and replace the first line with
AC_CHECK_LIB(osxfuse_i64,fuse_new, [FUSE_LIBS="-losxfuse_i64"],rather than
AC_CHECK_LIB(fuse,fuse_new, [FUSE_LIBS="-lfuse"],and see what happens?
hasse69
commented
4 years ago So, maybe the order in which to search for libraries should really be
osxfuse_i64 osxfuse fuse_ino64 fuse4x fuse dokanfuse1
This would effectively mean Linux users etc, would need to fail a few times before finding its fuse library. But we need to bring the "odd" birds to the front I guess. Another more complicated solution would be to check specifically for each OS and make decisions based on that. That is however something I would like to avoid though since if you ask me such tests are error prone. But I am a bit concerned about the fact that header files does not seem to be installed unless the compatibility layer is chosen and then what would happen?
richardsimko
commented
4 years ago Of course, but if I uninstall the compatibility layer I though it would go down and get to the libosxfuse line.
I tried with the new order and it worked well, the drive even gets a nice new icon as well!
hasse69
commented
4 years ago Yes, but if you drop the compatibility layer you lack the proper header files?
And it is not osxfuse you want, you want osxfuse_i64.
richardsimko
commented
4 years ago Ahh, then it makes sense!
However the new order you suggested (Putting AC_CHECK_LIB(osxfuse_i64,fuse_new, [FUSE_LIBS="-losxfuse_i64"], at the top) still doesn't work without the compatibility layer, still missing the headers. But perhaps that was expected?
hasse69
commented
4 years ago It was expected judging from your findings, yes. What we had to check was that mixing the headers from the compatibility layer and the "real" OSXFUSE library still works. And if I interpret your tests correctly it in fact did?
richardsimko
commented
4 years ago Yep! Granted I haven't tried every aspect of rar2fs but mounting a basic test RAR-file worked well.
hasse69
commented
4 years ago Ok, please try some more "advanced" operations on your file system and then report back. It is vital we understand the effect of mixing these two before we can safely change the search order according to my last suggestion.
hasse69
commented
4 years ago And honestly I think you should post a question on the OSXFUSE forum to get a better understanding of why only the compatibility layer installs the required header files for any FUSE based file system.
richardsimko
commented
4 years ago I tried mounting multi-part RARs as well which works, not sure what else I should test for as that's all I use it for. I can run this for a few days and report back if I encounter any issues.
hasse69
commented
4 years ago Please do that. I will prepare a patch for this but will put it on hold until you report back your findings. Thanks a lot for you patience and assistance in testing this.
richardsimko
commented
4 years ago Sounds good! Thank you for all the help :)
hasse69
commented
4 years ago Btw, I checked the issue tracker on OSXFUSE and according to that there should be header files installed in /usr/local/include/osxfuse. Can you check if that is the case on your system?
richardsimko
commented
4 years ago Hmm, yeah there is indeed a fuse.h there even if I install it without the compatibility layer.
I have:
drwxr-xr-x 10 root wheel 320B 5 Dec 13:32 fuse
-rw-r--r-- 1 root wheel 246B 5 Dec 13:32 fuse.hand in /fuse there is:
-rw-r--r-- 1 root wheel 37K 5 Dec 13:32 fuse.h
-rw-r--r-- 1 root wheel 15K 5 Dec 13:32 fuse_common.h
-rw-r--r-- 1 root wheel 714B 5 Dec 13:32 fuse_common_compat.h
-rw-r--r-- 1 root wheel 7.9K 5 Dec 13:32 fuse_compat.h
-rw-r--r-- 1 root wheel 350B 5 Dec 13:32 fuse_darwin.h
-rw-r--r-- 1 root wheel 54K 5 Dec 13:32 fuse_lowlevel.h
-rw-r--r-- 1 root wheel 6.8K 5 Dec 13:32 fuse_lowlevel_compat.h
-rw-r--r-- 1 root wheel 7.3K 5 Dec 13:32 fuse_opt.hAh, ok. Then what you should try is to configure like this
./configure --with-fuse=/usr/local/include/osxfuseLet's see if that works now without the compatibility layer installed.
richardsimko
commented
4 years ago That worked perfectly, now built and running without the compatibility layer 🎉
hasse69
commented
4 years ago Great! Then I will await your feedback to make sure everything runs smoothly for a couple of days before submitting the patch.
hasse69
commented
4 years ago Any updates here?
richardsimko
commented
4 years ago Still working well! I use it mostly for multipart archives. Notifications about file changes are also working as expected (Which it wasn't before) so I'm happy 🎉
hasse69
commented
4 years ago Thanks for the feedback. Patch is now merged into master.
richardsimko
commented
4 years ago Awesome, thanks for all your help and the great software! Tack så mycket ;)
I had a working installation of rar2fs 1.26.0 but decided to update both that and osxfuse. Unfortunately this has now completely broken the installation. I have issues similar to #119 but I've tried all the troubleshooting there to no avail.
When I mount a file (
rar2fs -d ~/Downloads/test/example.rar ~/Downloads/test/mnt -o volname=test) the directory I'm targeting disappears from Finder and does not appear as an external drive as it used to. If I try to access it through the terminal I get an IO error. The output from rar2fs does not really point to anything obvious:I've built rar2fs using unrar 5.9.2 and I've tried osxfuse 3.10.4 (Latest) as well as 3.8.3 but none of them worked.