Closed GoogleCodeExporter closed 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
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
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
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
[deleted comment]
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
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
Original comment by hans.bec...@gmail.com
on 7 Mar 2014 at 4:30
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
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
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
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
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
No problem. Glad you solved it :)
Closing the case.
Original comment by hans.bec...@gmail.com
on 11 Mar 2014 at 2:23
Original issue reported on code.google.com by
jyhpsy...@gmail.com
on 7 Mar 2014 at 3:12