Cannot list any contents in archive on FreeBSD 10.

[hasse69]

What steps will reproduce the problem?

1. Compile rar2fs using any dirty method currently available.
2. mount archive.
3. run ls.

What is the expected output? What do you see instead?

• It should display contents of archive. but, it doesn't. ls displays just empty directory.

What version of the product are you using? On what operating system?

• FreeBSD 10.0-STABLE x86-64, rar2fs r463, libunrar 5.0.14

Please provide any additional information below.

• Currently I used ~46GiB RARv5 archive file. Because of I cannot using WINE under FreeBSD Currently(missing i386 support when compiling kernel), I cannot perform test with smaller file.

Original issue reported on code.google.com by jyhpsycho on 2014-03-07 03:12:14

[hasse69]

Hmm... I tested with my own patch version of libunrar which has an issue when reading
device file...

With pure version of libunrar, ls returns wrong information instead of not display
anything. I'll report debug messages later.

Original issue reported on code.google.com by jyhpsycho on 2014-03-07 03:19:38

[hasse69]

ls output : 

# ls -la TEST/
total 45710634
drwxr-xr-x  17 root  wheel           25 Mar  6 22:57 .
drwxr-xr-x   6 root  wheel          384 Mar  7 12:04 ..
-rw-r--r--   1 root  wheel  46807678978 Jun 26  2013 [BDMV][

 - Actually that is directory, not file. name is very longer than currently displayed
one.



Debug messages:

# rar2fs-read-only/rar2fs -o ro,allow_other,debug /TEMP.rar TEST
rar2fs[87964]: mounted /mnt/shm/TEST
unique: 1, opcode: INIT (26), nodeid: 0, insize: 56, pid: 87965
INIT: 7.8
flags=0x00000000
max_readahead=0x00010000
rar2_init()   
   INIT: 7.19
   flags=0x00000010
   max_readahead=0x00010000
   max_write=0x00020000
   max_background=0
   congestion_threshold=0
   unique: 1, success, outsize: 40
unique: 2, opcode: GETATTR (3), nodeid: 1, insize: 40, pid: 87966
getattr /
rar2_getattr2()   /
MISS    /
STAT retrieved for //
   unique: 2, success, outsize: 112
unique: 3, opcode: OPENDIR (27), nodeid: 1, insize: 48, pid: 87966
opendir flags: 0x0 /
rar2_opendir()   /
   opendir[34401919040] flags: 0x0 /
   unique: 3, success, outsize: 32
unique: 4, opcode: STATFS (17), nodeid: 1, insize: 40, pid: 87966
statfs /
rar2_statfs()   /
   unique: 4, success, outsize: 96
unique: 5, opcode: GETATTR (3), nodeid: 1, insize: 40, pid: 87966
getattr /
rar2_getattr2()   /
MISS    /
STAT retrieved for //
   unique: 5, success, outsize: 112
unique: 6, opcode: READDIR (28), nodeid: 1, insize: 64, pid: 87966
readdir[34401919040] from 0
rar2_readdir2()   
listrar()   /   arch=/TEMP.rar
Looking up /[BDMV][ in cache
Adding /[BDMV][ to cache
dump_dir_list()   /
   unique: 6, success, outsize: 112
unique: 7, opcode: GETATTR (3), nodeid: 1, insize: 40, pid: 87966
getattr /
rar2_getattr2()   /
MISS    /
STAT retrieved for //
   unique: 7, success, outsize: 112
unique: 8, opcode: GETATTR (3), nodeid: 1, insize: 40, pid: 87966
getattr /
rar2_getattr2()   /
MISS    /
STAT retrieved for //
   unique: 8, success, outsize: 112
unique: 9, opcode: LOOKUP (1), nodeid: 1, insize: 48, pid: 87966
LOOKUP /[BDMV][
getattr /[BDMV][
rar2_getattr2()   /[BDMV][
   NODEID: 2
   unique: 9, success, outsize: 136
unique: 10, opcode: GETATTR (3), nodeid: 2, insize: 40, pid: 87966
getattr /[BDMV][
rar2_getattr2()   /[BDMV][
   unique: 10, success, outsize: 112
unique: 11, opcode: READDIR (28), nodeid: 1, insize: 64, pid: 87966
   unique: 11, success, outsize: 16
unique: 12, opcode: RELEASEDIR (29), nodeid: 1, insize: 64, pid: 87966
releasedir[34401919040] flags: 0x0
rar2_releasedir()   
   unique: 12, success, outsize: 16
unique: 13, opcode: GETATTR (3), nodeid: 1, insize: 40, pid: 87966
getattr /
rar2_getattr2()   /
MISS    /
STAT retrieved for //
   unique: 13, success, outsize: 112
unique: 14, opcode: GETATTR (3), nodeid: 1, insize: 40, pid: 87966
getattr /
rar2_getattr2()   /
MISS    /
STAT retrieved for //
   unique: 14, success, outsize: 112

Original issue reported on code.google.com by jyhpsycho on 2014-03-07 03:27:42

[hasse69]

I think there's some issue related on iconv() function sets mentioned issue 31. It should
be re-test when issue 31 is resolved...

Original issue reported on code.google.com by jyhpsycho on 2014-03-07 04:46:06

[hasse69]

I do not think so, iconv is actually not used. The code is only prepared to use it so
I doubt that is has anything to do with it. Would be surprised if it did.
What file are you testing? Is this the same archive as you provided in some previous
issue report? 

Can you please tell me how to get FUSE running on FreeBSD 10 :) When I start rar2fs
it complains about a missing FUSE device. Do I need add something to rc.conf?

Original issue reported on code.google.com by hans.beckerus on 2014-03-07 06:43:58

[hasse69]

I used 'kldload fuse' to get fuse going, does not seem that adding fusefs_enable="YES"
to rc.conf has any effect?

Anyway, I tried with an example.rar file and I do not see any problems. I did however
detect a severe issue that resulted in a crash on FreeBSD for folders inside RAR archives
:( but r464 should resolve that problem. But I have not been able to reproduce your
specific problem. Any chance that you might have some other (less sized) archive suffering
from the same issue that you can share?

Original issue reported on code.google.com by hans.beckerus on 2014-03-07 08:36:26

[hasse69]

No, That file cannot provided because that's size is very large. On other issues reported
by me, provided archive are not original file, too -  But I just maked much smaller
examples that can reproduce same problem. I'll try if that is reproducible with smaller
files, too.

I'm currently reinstalling FreeBSD 10. I'll test when that's done. But, I describe
what I did.

On FreeBSD 10, kernel module part of FUSE is already included in base system. Thus,
I installed just fusefs-libs using pkg.

# pkg install fusefs-libs

I didn't test fusefs_enable=YES, but I manually loaded fuse module via:

# kldload fuse

I'll test fusefs_enable=YES later, and find some smaller example can reproduce this.

Original issue reported on code.google.com by jyhpsycho on 2014-03-07 11:31:02

[hasse69]

(No text was entered with this change)

Original issue reported on code.google.com by hans.beckerus on 2014-03-07 16:30:19

[hasse69]

Have not been able to reproduce this yet. I did get a similar behaviour while run-time
linking towards a different version of libunrar.so than rar2fs was compiled against.
Please make sure that is not also the case here. 

Original issue reported on code.google.com by hans.beckerus on 2014-03-09 10:45:20

[hasse69]

Hmm... There's no issue you say because I'm use only static libunrar.a to build rar2fs.
Thus rar2fs doesn't require libunrar.so. And, I do not install FreeBSD's ports one
- actually rar2fs(and libunrar) on ports currently is very old version.

libunrar.a can build with following command on unrar source dir:
# ar -r libunrar.a *.o
# rm libunrar.so
I remove libunrar.so explicitly because compiler uses shared version of library by
default if there's both static and shared library.

I didn't any another test yet; I'm facing some problems with my system. It's very time-consuming
work to make my system usable... :( There's still that problem - rar2fs cannot display
file list properly yet.

I'll test if it reproducible with another, smaller file as soon as possible.

Original issue reported on code.google.com by jyhpsycho on 2014-03-09 11:12:39

[hasse69]

Right. I will try some more RAR5 archives from my end. 

Original issue reported on code.google.com by hans.beckerus on 2014-03-09 11:52:52

[hasse69]

OH MY GOD!!! It seems that there's no problem?! I'm very confused now... I can't reproduce
it even original archive I used! :(

My archive used at issue report has entries that contains CJK characters. On FreeBSD's
default text console, that characters can't display properly. But, If rar2fs properly
works, ls should display '?' character (# of byte of that character) times, then I
reported this issue.

ERRATA : Oh, Entry that in file list at #2 is file, not directory... sorry. I have
some mistake that actually processed 2 times...

Listing what if it works :
# ls -la TEST
total 45710634
drwxr-xr-x  18 root  wheel           24 Mar 11 21:17 .
drwxr-xr-x   7 root  wheel          448 Mar 11 21:30 .
-rw-r--r--   1 root  wheel  46807678978 Jun 26  2013 [BDMV][?????????]???????????????.rar

Actually displayed before :
# ls -la TEST/
total 45710634
drwxr-xr-x  17 root  wheel           25 Mar  6 22:57 .
drwxr-xr-x   6 root  wheel          384 Mar  7 12:04 ..
-rw-r--r--   1 root  wheel  46807678978 Jun 26  2013 [BDMV][

But, after reinstall FreeBSD, ls displays former listing, not latter. There's no any
problem to access that's contents - even mounting archive in it, too!



I think there's some strict test to this issue to ensure there's no any problem, but
I guess there's no rar2fs problem at least... I installed custom-compiled version of
FreeBSD based on nearly latest STABLE source tree, and use r466 now. But it's different
condition that I found this issue, therefore I'll test on 10.0-RELEASE, r463 as soon
as possible. I reported that I used 10.0-STABLE when report this issue, but major difference
is just compiles ZFS module into kernel.

Original issue reported on code.google.com by jyhpsycho on 2014-03-11 13:32:20

[hasse69]

I found what was wrong. On FreeBSD, there's no any language and encoding setting by
default! with correct LANG value, ls works normally.

I think it can be closed with 'INVALID' tag. I'm sorry for you to spend time with this
issue, and thanks for your effort that think and discuss many issues with me despite
of poor english... :)

Original issue reported on code.google.com by jyhpsycho on 2014-03-11 13:54:14

[hasse69]

No problem. Glad you solved it :)
Closing the case.

Original issue reported on code.google.com by hans.beckerus on 2014-03-11 14:23:22