Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

RAR contents inside archive not listed #22

Closed
hasse69 opened this issue Mar 13, 2015 · 10 comments
Closed

RAR contents inside archive not listed #22

hasse69 opened this issue Mar 13, 2015 · 10 comments
Labels
Defect Priority-Medium

Comments

@hasse69
Copy link
Owner

hasse69 commented Mar 13, 2015

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 fafarago on 2014-01-13
@hasse69 hasse69 closed this as completed Mar 13, 2015
@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

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 issue reported on code.google.com by hans.beckerus on 2014-01-14 00:29:33

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

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

Original issue reported on code.google.com by hans.beckerus on 2014-01-14 09:41:35

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

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 issue reported on code.google.com by fafarago on 2014-01-15 01:33:31

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

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

Original issue reported on code.google.com by fafarago on 2014-01-15 01:34:54

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

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 issue reported on code.google.com by fafarago on 2014-01-16 23:56:25

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

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 issue reported on code.google.com by hans.beckerus on 2014-01-17 00:11:20

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

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 issue reported on code.google.com by hans.beckerus on 2014-02-24 21:28:39

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

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 issue reported on code.google.com by fafarago on 2014-03-07 00:52:56

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

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 issue reported on code.google.com by hans.beckerus on 2014-03-07 06:50:46

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

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 issue reported on code.google.com by fafarago on 2014-03-08 04:16:38

@andree392 andree392 mentioned this issue Jul 13, 2021
Closed
@Nischi85 Nischi85 mentioned this issue Oct 9, 2022
Closed
fdegros pushed a commit to fdegros/rar2fs that referenced this issue Nov 29, 2023
@hasse69
* Released 1.20.0
39d51f1 
* Turned off support for block special device mounts other
  than for Linux platforms. It does not make much sense trying
  to support it any where else due to possible read alignment
  restrictions.

* Built and tested against UnRAR source 5.10 beta 1 (5.1.1)

* [rar2fs hasse69#34]

  Fixed a problem with old style archives split into more
  than 101 files.

* Now returning "No such file or directory" instead of
  "Input/output error" when trying to read information
  for a file outside an archive or which does not exist
  at all (libunrar5 only).

* Fixed an issue when retrieving file information (#info)
  that could have resulted in an infinite loop.

* Fixed an issue with resolving symbolic links for
  legacy archives in combination with libunrar5.

* Corrected some issues that caused compilation failures
  for UnRAR source 4.1.x.

* Corrected a problem seen on e.g. FreeBSD for which closedir()
  was called with a NULL pointer resulting in a crash.

* [rar2fs hasse69#31]

  Corrected some compilation errors on FreeBSD (and also other
  platforms that sets HAVE_SETXATTR).

* Mounting block special files on Linux can now benefit from
  fmemopen() when supported.

* Enabled syslog support

* [rar2fs hasse69#22]

  Now may fall back to the old workaround from 1.19.2 that
  should be working also for (some!?) uClibc versions of
  fmemopen().

* Corrected some additional problems with the solution
  for issue hasse69#22.

* Added support for presenting high-resolution time stamp in
  RAR5 archives (thanks to jyhpsycho for the initial patch).
  Legacy archives still require a new version of UnRAR source
  before it can be enabled.

* [rar2fs hasse69#28]

  Fixed problem with mounting a block special file that
  resulted in a crash due to incorrect use of mmap() and
  fmemopen().

* Added a missing check for errors from fmemopen()

* [rar2fs hasse69#29]

  Fixed a minor calculation error in the file time stamp
  'seconds' part as provided by libunrar (MS-DOS time format).

* Removed 'INSTALL' from SVN trunk
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Defect Priority-Medium
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@hasse69