Broken with unrar >= 5.8.1 ?

[konstantinblaesi]

I built rar2fs and unrar from the latest master using https://github.com/hasse69/rar2fs/commit/ea4c422b9858bd9e2358850651185aa4c2ff3138 and https://github.com/pmachapman/unrar/commit/b5991fd79e83993121435769a3e4e2b2c6c98da9 Directory listings look ok, but reading a file using dd would read 0 bytes. According to git bisect it breaks with this commit https://github.com/pmachapman/unrar/commit/6f111e1961b8db5e148b5894f36fbe4020962a8c Is this a known issue?

[hasse69]

Nothing that I am aware of at least. This project uses only the unrar library sources directly from RARLAB as reference so this specific commit you are referring to has never officially been tested. I will try to download 5.8.1 from the RARLAB site and see if I can make something out of it. Latest 5.9.2 has been tested successfully though.

Is this problem affecting both compressed and uncompressed archives?

[hasse69]

I have now tested 5.8.1 downloaded from RARLAB with a clean compile of rar2fs and I cannot see any problems what so ever. Both compressed and uncompressed archives read back fine using e.g. dd. Would it be possible for you to post the result of ldd <path to your rar2fs binary>, just wish to see that your linkage looks ok. Also be aware, unless you already discovered that, that later versions of rar2fs puts the binary under the src folder and not directly in the root of the repo. Actually did that mistake myself a couple of times :)

For the record I have now also tested the commits https://github.com/pmachapman/unrar/commit/6f111e1961b8db5e148b5894f36fbe4020962a8c and https://github.com/pmachapman/unrar/commit/b5991fd79e83993121435769a3e4e2b2c6c98da9 and they both seems to work just fine. At least for me.

[konstantinblaesi]

OS is a fresh centos 8. I was using static linking and mounted using

/usr/src/rar2fs/src/rar2fs -d /source /target

ldd /usr/src/rar2fs/src/rar2fs

linux-vdso.so.1 (0x00007ffdbb6b7000)
libfuse.so.2 => /lib64/libfuse.so.2 (0x00007f5241af7000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f52418f3000)
librt.so.1 => /lib64/librt.so.1 (0x00007f52416ea000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f5241355000)
libm.so.6 => /lib64/libm.so.6 (0x00007f5240fd3000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f5240dbb000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5240b9b000)
libc.so.6 => /lib64/libc.so.6 (0x00007f52407d8000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5241d36000)

Build steps for unrar where just

• change git commit
• make clean && make -j12

For rar2fs just some build.sh

#!/bin/sh

set -e

PREFIX=/usr
UNRAR_PATH=/usr/src/unrar

export CFLAGS="-O3 -fPIC"
export CXXFLAGS=$CFLAGS
export LDFLAGS="-fPIC"

STATIC="" # --disable-static-unrar

autoreconf -f -i
./configure --prefix=$PREFIX $STATIC --with-unrar=$UNRAR_PATH --with-unrar-lib=$UNRAR_PATH
make clean && make -j12

[hasse69]

Was that a typo or did you not use make lib when building the unrar source?

Anyway, if I understand you correctly you observe this problem only starting with 5.8.1 and not any version before that. Also it affects all your archives.

If it affects all your archives would it be possible for you to create a very small test archive and then reproduce it? A small test archive might give us a chance to compare output etc since this might be related to something initialized differently in our environments. Since you run using the -d flag I assume you did not catch any strange output or error messages coming from rar2fs itself.

If it does not affect all your archives then I would probably need to get hold of one that fails for you.

EDIT:

Also I would not recommend you to change what rar2fs is handling for you here

export CFLAGS="-O3 -fPIC"
export CXXFLAGS=$CFLAGS
export LDFLAGS="-fPIC"

Especially with respect to -fPIC since it only applies to libunrar and is handled by its own makefile. You should not need it anywhere else. There is nothing really to gain by using -O3 either but that would be safe if you believe it is necessary.

Regarding my first comment about make lib. If it is was a typo then forget it, but if it was not it might very well explain what you see since you would use a stale library not matching the header files in the repo. This since a git checkout keeps any artifacts created by a previous build and make clean does not seem to remove them either. We should probably report that upstream since that is clearly a bug if you ask me.

[konstantinblaesi]

Ah sorry for the noise, I didn't build unrar in a long time and must've messed up. After doing make lib it works as expected :)

[hasse69]

I will report the make clean issue upstream. I think it is supposed to remove any previously built artifacts.