search

hasse69 / rar2fs

FUSE file system for reading RAR archives
https://hasse69.github.io/rar2fs/
GNU General Public License v3.0
279 stars 27 forks source link

Cannot listing files in archive created with -ep2 option #68

Closed jyhpsycho closed 7 years ago

jyhpsycho commented 7 years ago

The issue which is observed during issue #49 is finally reproduced, which blocks testing patch some time (see https://github.com/hasse69/rar2fs/issues/49#issuecomment-272450364).

UNRAR 5.40 freeware Copyright (c) 1993-2016 Alexander Roshal

Archive: TEST.rar Details: RAR 5

    Name: dev/shm/TEST/TEST1
    Type: File
    Size: 1024

Packed size: 1024 Ratio: 100% mtime: 2017-02-05 11:43:21,240 Attributes: ..A.... CRC32: DDA8339D Host OS: Windows Compression: RAR 5.0(v50) -m0 -md=128K

    Name: dev/shm/TEST/TEST2
    Type: File
    Size: 1024

Packed size: 1024 Ratio: 100% mtime: 2017-02-05 11:43:23,090 Attributes: ..A.... CRC32: 01511C2B Host OS: Windows Compression: RAR 5.0(v50) -m0 -md=128K

 Service: EOF


Note that it stores full path except drive letter. It's what `-ep2` option does. This is default behavior if the archive is created using absolute path to specify input files. For the case of using relative path, it does not occur.

I'll attach the sample. [TEST.zip](https://github.com/hasse69/rar2fs/files/752713/TEST.zip)
jyhpsycho commented 7 years ago

With -ep3 option, it also includes driver letter, and it does not work like -ep2. The result of unrar on this case is:

$ unrar vta TEST.rar

UNRAR 5.40 freeware      Copyright (c) 1993-2016 Alexander Roshal

Archive: TEST.rar
Details: RAR 5

        Name: Z_/dev/shm/TEST/TEST1
        Type: File
        Size: 1024
 Packed size: 1024
       Ratio: 100%
       mtime: 2017-02-05 11:43:21,240
  Attributes: ..A....
       CRC32: DDA8339D
     Host OS: Windows
 Compression: RAR 5.0(v50) -m0 -md=128K

        Name: Z_/dev/shm/TEST/TEST2
        Type: File
        Size: 1024
 Packed size: 1024
       Ratio: 100%
       mtime: 2017-02-05 11:43:23,090
  Attributes: ..A....
       CRC32: 01511C2B
     Host OS: Windows
 Compression: RAR 5.0(v50) -m0 -md=128K

     Service: EOF
jyhpsycho commented 7 years ago

I think that it's difficult to distinguish the path name is included by real contents(relative path) or base path of it. Thus the expect result is one of which suggested above(ideal), or at least:

$ ls -lAR --full-time X
X:
total 0
drwxr-xr-x 3 rar_work users 60 2017-02-05 12:14:37.947352585 +0900 dev

X/dev:
total 0
drwxr-xr-x 3 rar_work users 60 2017-02-05 12:14:45.599150489 +0900 shm

X/dev/shm:
total 0
drwxr-xr-x 2 rar_work users 80 2017-02-05 12:15:20.092239475 +0900 TEST

X/dev/shm/TEST:
total 8
-rw-r--r-- 1 rar_work users 1024 2017-02-05 11:43:21.240547106 +0900 TEST1
-rw-r--r-- 1 rar_work users 1024 2017-02-05 11:43:23.090505706 +0900 TEST2
jyhpsycho commented 7 years ago

I found the difference!

$ unrar vta TEST.rar

UNRAR 5.40 freeware      Copyright (c) 1993-2016 Alexander Roshal

Archive: TEST.rar
Details: RAR 5

        Name: dev/shm/TEST/TEST_DIR/TEST1
        Type: File
        Size: 1024
 Packed size: 1024
       Ratio: 100%
       mtime: 2017-02-05 11:43:21,240
  Attributes: ..A....
       CRC32: DDA8339D
     Host OS: Windows
 Compression: RAR 5.0(v50) -m0 -md=128K

        Name: dev/shm/TEST/TEST_DIR/TEST2
        Type: File
        Size: 1024
 Packed size: 1024
       Ratio: 100%
       mtime: 2017-02-05 11:43:23,090
  Attributes: ..A....
       CRC32: 01511C2B
     Host OS: Windows
 Compression: RAR 5.0(v50) -m0 -md=128K

        Name: dev/shm/TEST/TEST_DIR
        Type: Directory
       mtime: 2017-02-05 12:19:32,484
  Attributes: ...D...
       CRC32: 00000000
     Host OS: Windows
 Compression: RAR 5.0(v50) -m0 -md=0K

     Service: EOF

As you can see, the header entry of base path is not included. More precisely, The header entry of TEST_DIR is included on archive, dev/shm/TEST is not.

hasse69 commented 7 years ago

Yes, I am aware of this difference. Some archives does not have an entry for the basedir or it is placed last instead of first. I compensate for that but I now realize it assumes paths are relative so that only the basedir needs to be handled separately. I am not sure how using absolute paths really match well with a file system mount point, to me it does not make much sense to support it. The paths are expected to be relative to the mount point. Too much logic for a very narrow use case if you ask me. But I will check how much work it is.

hasse69 commented 7 years ago

Does not seem to be that much work to fix this. Will look into it.

hasse69 commented 7 years ago

Try this patch.

For some reason adding your TEST.rar file inside another RAR does not work. Something seems different also when archives like this is added inside another archive. I do not have time to dig into that, so for now abs paths is not supported for embedded RARs. If that is needed, stack your file systems instead. That works just fine. I am very close to removing the built-in support for embedded archives completely because it is limited in functionality and makes the code complex and error prone. Stacking is a much better approach for this.

hasse69 commented 7 years ago

patch.txt

jyhpsycho commented 7 years ago

Yeah, it seems to work. Thanks :-)

I agree with your opinion; In fact, I'm always use --flat-only option, which disables parsing embedded RAR. It operates unwanted way for me. I think that 'stacking' is more general way to treat archive-in-archive than nested parsing.

hasse69 commented 7 years ago

Thanks for trying it out, but unfortunately regression failed for e.g. issue #42. This patch needs some more work.

hasse69 commented 7 years ago

Try this one instead

patch.txt

jyhpsycho commented 7 years ago

Good, I found the regression after testing on normal use case :-( Now it works with sample archive, generated one with volume option(both of header encryption is enabled or not), and one of normal use case for me.

hasse69 commented 7 years ago

Thanks, I will release this patch then and close the issue.