-[TC8.50rc1] Errors when browsing multi-volume rar archives

[atomix]

I am an experienced user of TotalCmd, and as such I use specific settings in wincmd.ini to let me work as an advanced user, and not to get things in my way of working. Here are some relevant settings related to the packer:

[Packer]
ExpertMode=1
OpenPartial=1
ZipLikeDirectory=1

Now let me illustrate the problem encountered in TC 8.50 rc1 (and betas). Make a multi-volume rar archive containing these files:

test.rar
- Folder\File1
- Folder\File2
- File3

test.r00
- File3 (continued)

test.r01
- File3 (continued)
- File4
- File5

Now let's move/copy the test.rar file only to another folder and open there (using Ctrl-PgDown). When using TotalCmd 8.01 (and earlier) I can go to Folder and open (F3 view) File1 and File2 without any errors. Of course, when I try to open File3 I am prompted to 'insert disk number r00' (as this is missing from the same folder where .rar is). This is actually the normal behavior up to 8.01 and it is perfectly fine.

However, when using TC 8.50 to do the same operation I get a first error to 'insert disk number r00' as soon as I try to open the .rar file. After I cancel the dialog, I get another error saying 'Error in packed file test.rar'. After I press OK, I am allowed to get into the .rar archive but I see only Folder\File1, Folder\File2 and no File3 at all (which should be shown here). Entering the Folder to reach the File1 and File2 I get again the two errors just described (when entering the archive). Opening the files File1 and File2 occurs correctly with no errors. However, I get 4 error messages before doing so.

This behavior is not only inconsistent with earlier TC versions, but it is also very annoying as it stands in the way of working, despite having TC set to advanced mode for packers. I truly hope that Christian will change this. Thank you!

[Horst.Epp]

This is unfortunately controlled by the Unrar.dll from rarlabs which is now the one which supports the new RAR 5.0 format.
So I guess Christian can't get the old behaviour.

What I not understand is why so many poeble struggle with incomplete archives. I had this last time with archives on Diskettes.

[atomix]

That is not the case actually. I have tested the same scenario using TC 8.01 and 8.50 together with unrar.dll (4.20.1.488 and earlier, and the new 5.0.100.967). In all cases TC 8.01 works fine, while TC 8.50 throws some errors. So it is not because of the unrar.dll but because of TCmd, unfortunately.

[ghisler(Author)]

TC 8.01 doesn't use unrar.dll to read the RAR file names and details, only to extract the actual data. Since the RAR5 format is completely different and quite complex, I decided to rely on unrar.dll now to read the file names. I'm also doing this to support header-encrypted RAR files, which could not be browsed in TC 8.01 and older.

[atomix]

This is very unfortunate, and while it explains the cause it does not solve the problem. Would it possible to keep the old style of reading the rar archives and rely on unrar.dll only when a rar5 archive is encountered?

Concerning the many errors shown, I would completely understand the first one asking for the next volume but if I cancel the dialog (ESC) asking for the next volume then I should be allowed to browse and view the content of the current rar volume without any additional errors. Is TC able to handle this properly?

BTW, what is the error code given by unrar.dll to TC in this case?

unrar.h
#define ERAR_END_ARCHIVE 10
#define RAR_VOL_ASK 0
#define RAR_VOL_NOTIFY 1
#define RAR_SKIP 0
#define RAR_TEST 1
#define RAR_EXTRACT 2

Perhaps a custom unrar.dll could be compiled?!

[Sir_SiLvA]

This is very unfortunate, and while it explains the cause it does not solve the problem. Would it possible to keep the old style of reading the rar archives and rely on unrar.dll only when a rar5 archive is encountered?

To solve the problem write to rarlab to fix this *rap*

[atomix]

This is still not fixed even with the new unrar.dll (5.1.100.1067) included in TC 8.50 RC2.

Moreover, it is unclear why this thread was moved here in the section 'TC Behaviour which will not be changed', since this report is about a behavior that WAS changed and want a way to have it unchanged.

[ghisler(Author)]

Sorry, this will not be changed because of how multi-volume archives are handled now.

[atomix]

Christian, please consider the following scenario.

As TC handles the errors thrown by the unrar.dll, you can still do it properly by neglecting the specific error code when listing or unpacking files that are completely present in the archive (providing that expert mode is enabled in wincmd.ini). The error/warning about missing next file should be shown only when the user tries to unpack the whole archive and the next volume is missing - but this is fully understandable.

[FrankCullens323]

Thanks atomix for the answer. This makes things much clearer.

[NinaClark761]

What is the best possible solution that can be tried in such a situation?