RAR contents inside archive not listed

[GoogleCodeExporter]

What steps will reproduce the problem?
1. build rar2fs-1.19.0 without fmemopen support
2. mount a rar file which contains another rar file inside
3. access the directory

What is the expected output? What do you see instead?
expected output is the listing of the contents of the contained rar file. 
Instead you get a listing without this, an error (in ls) and the rar file with 
unknown metadata. e.g.
root@alexandria:/mnt/md0/downloads# ls -l test2
ls: cannot access test2/inner_archive.rar: No such file or directory
total 296
-rw-r--r-- 1 root root 303029 Jan  8 21:06 file.idx
?????????? ? ?    ?         ?            ? inner_archive.rar

What version of the product are you using? On what operating system?
Using rar2fs-1.19.0 with unrar-5.0.14 on an armv5tel with uClibc.

Please provide any additional information below.
unrar-4.2.24 is working. The contents of the rar files are:
root@alexandria:/mnt/md0/downloads# unrar l test/bob.rar 

UNRAR 5.01 freeware      Copyright (c) 1993-2013 Alexander Roshal

Archive: test/bob.rar
Details: RAR 4

 Attributes      Size    Date   Time   Name
----------- ---------  -------- -----  ----
    ..A....    303029  08-01-14 21:06  file.idx
    ..A....   7884165  08-01-14 21:31  inner_archive.rar
----------- ---------  -------- -----  ----
              8187194                  2

Original issue reported on code.google.com by fafar...@gmail.com on 13 Jan 2014 at 11:37

[GoogleCodeExporter]

Thanks for the issue report. 
The problem is caused by the fact that libunrar5 introduces a new feature which 
is called QuickOpen. Due to that, the file position is reset every time an 
archive is opened. rar2fs assumes the old behaviour for which the file position 
was left at the position it was set to before the archive is initialized. The 
reason why it works when fmemopen() is used is because fmemopen() actually 
positions the file pointer internally  and resets it to 0 pretending it is the 
start of a file which is not the case for fopen()+fseek(). It is possible to 
work around this, but in the absence of fmemopen() support, the functionality 
is slightly limited but should still cover most of the common cases. The only 
way to solve this and to cover 100% of the cases is to modify the UnRAR 
library, which is currently not a feasible action, especially since it is doing 
nothing wrong really. I will commit a new patch release of rar2fs as soon as 
possible.

Original comment by hans.bec...@gmail.com on 14 Jan 2014 at 12:29

• Changed state: Started

[GoogleCodeExporter]

There is now a patch release 1.19.1 available for download.
Please report back if this version does not resolve your problem.

Original comment by hans.bec...@gmail.com on 14 Jan 2014 at 9:41

• Changed state: Fixed

[GoogleCodeExporter]

This patch resolves my problem, I can correctly list and access files on 
libunrar5.
Regarding the fmemopen issue: my version of uClibc is compiled without support 
for this function. There is no limitation as to why it should not be available. 
 This function is simply a glibc extension and disabled my default. 

Answer Y to support the glibc 'custom stream' extension functions               
                                        �     � fmemopen(), 
open_memstream(), and fopencookie().                                            
                            �
  �                                                                                                                         �     � NOTE: There are some minor differences regarding seeking behavior.                                                      �
  �                                                                                                                         �     � Most people will answer N.                                                                                              �
  �                                                                                                                         �

Original comment by fafar...@gmail.com on 15 Jan 2014 at 1:33

[GoogleCodeExporter]

I will build an uClibc version with this enabled and report back. 

Original comment by fafar...@gmail.com on 15 Jan 2014 at 1:34

[GoogleCodeExporter]

Hi,
A last comment on the issue: I have compiled a version of uClibc with fmemopen 
support, and let it loose on rar2fs. Version 1.19.0 has the same issue as in my 
original post; 1.19.1 works properly. I guess uClibc's comment that "There are 
some minor differences regarding seeking behavior." is indeed correct.

Original comment by fafar...@gmail.com on 16 Jan 2014 at 11:56

[GoogleCodeExporter]

I have so far not seen a system with fmemopen() support that failed like you 
reported here. But uCLibc is not something that I have been testing recently. 
It might very well be that uCLibc has implemented this differently. Another 
reason maybe to try eglibc instead? ;) 

Case closed.

Original comment by hans.bec...@gmail.com on 17 Jan 2014 at 12:11

• Changed state: Verified

[GoogleCodeExporter]

Would be great if you could try the latest version in trunk (that would be 
1.19.13) and verify that this still works as expected. Had to adjust the 
workaround somewhat.

Original comment by hans.bec...@gmail.com on 24 Feb 2014 at 9:28

[GoogleCodeExporter]

Hi Hans, 
The latest version I could find is 1.19.8, which is also listed on the main 
page as latest version. I can confirm it is working as expected. 

A bit annoying that Google has moved the files to docs as what gets totally 
confused about the file name and the scripts I use to build for my Nas needed 
some manual interventions :) 

Original comment by fafar...@gmail.com on 7 Mar 2014 at 12:52

[GoogleCodeExporter]

Thanks for testing.
I was referring to the version in SVN trunk. Is it possible for you to test it?

# svn checkout http://rar2fs.googlecode.com/svn/trunk/ rar2fs-read-only
# autoreconf -ifs
# configure <options>

Original comment by hans.bec...@gmail.com on 7 Mar 2014 at 6:50

[GoogleCodeExporter]

Ah sorry, didn't try that one. 
I did a checkout from svn and tested that version.  It works as far as my 
testrars are concerned. Thanks! 

Original comment by fafar...@gmail.com on 8 Mar 2014 at 4:16