ClosestStorm / rar2fs

Automatically exported from code.google.com/p/rar2fs
GNU General Public License v3.0
0 stars 0 forks source link

Cannot list any contents in archive on FreeBSD 10. #33

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
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 jyhpsy...@gmail.com on 7 Mar 2014 at 3:12

GoogleCodeExporter commented 9 years ago
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 comment by jyhpsy...@gmail.com on 7 Mar 2014 at 3:19

GoogleCodeExporter commented 9 years ago
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 comment by jyhpsy...@gmail.com on 7 Mar 2014 at 3:27

GoogleCodeExporter commented 9 years ago
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 comment by jyhpsy...@gmail.com on 7 Mar 2014 at 4:46

GoogleCodeExporter commented 9 years ago
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 comment by hans.bec...@gmail.com on 7 Mar 2014 at 6:43

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
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 comment by hans.bec...@gmail.com on 7 Mar 2014 at 8:36

GoogleCodeExporter commented 9 years ago
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 comment by jyhpsy...@gmail.com on 7 Mar 2014 at 11:31

GoogleCodeExporter commented 9 years ago

Original comment by hans.bec...@gmail.com on 7 Mar 2014 at 4:30

GoogleCodeExporter commented 9 years ago
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 comment by hans.bec...@gmail.com on 9 Mar 2014 at 10:45

GoogleCodeExporter commented 9 years ago
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 comment by jyhpsy...@gmail.com on 9 Mar 2014 at 11:12

GoogleCodeExporter commented 9 years ago
Right. I will try some more RAR5 archives from my end. 

Original comment by hans.bec...@gmail.com on 9 Mar 2014 at 11:52

GoogleCodeExporter commented 9 years ago
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 comment by jyhpsy...@gmail.com on 11 Mar 2014 at 1:32

GoogleCodeExporter commented 9 years ago
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 comment by jyhpsy...@gmail.com on 11 Mar 2014 at 1:54

GoogleCodeExporter commented 9 years ago
No problem. Glad you solved it :)
Closing the case.

Original comment by hans.bec...@gmail.com on 11 Mar 2014 at 2:23