+TC 8.5 Beta 4: Incomplete RAR files won't open

[gdpr deleted 6]

This is a limitation of the unrar dll: It can only show the contents of volumes starting with the first. So TC will show the contents of all volumes until the first gap.

In older versions, I read the contents of the RAR parts myself in my own code. Unfortunately the new RAR5 format is very complex, so I can no longer do that and use unrar.dll instead.

Perhaps you misunderstood the original request.

If you open the first part of a multi-volume archive, the archive content should be shown.

However, that does not work if the archive naming scheme is *.001, *.002, *.003, etc... In this case, opening *.001 shows only an empty list -- which is wrong.

By the way, UnRAR.dll does not have a problem opening a multi-volume RAR archive when using a naming scheme like *.001, *.002, *.003.

[gdpr deleted 6]

2Csimbi
Sorry, cannot reproduce. I just renamed one part of a multi-volume archive. TC then asks for the missing part when I open the first. I click on "Cancel". Then TC shows the files found until then.

Please make sure to use the latest beta 5 for this.

No, you got it wrong there. Look at this post, and pay attention to the archive naming given there.

[ghisler(Author)]

This isn't normal naming scheme of RAR multi-part archives.

[gdpr deleted 6]

This isn't normal naming scheme of RAR multi-part archives.

WinRAR and UnRAR.dll handle this just fine. I do not really understand your argumentation.

But, if you don't want to support this kind of naming scheme for whatever reason, then DO NOT SHOW an empty list -- that is totally wrong information given by TC --, just don't go into these files.

[ghisler(Author)]

Are they really multi-part RAR files, where a file stretches from one part to the next? Or just single part files with the wrong extension?

[gdpr deleted 6]

Just to make clear, there is no trickery involved for this file naming scheme to work. UnRAR.dll just handles it naturally.

The code below is a simplified C++ version of the C sample code that comes with the UnRAR.dll package. There are really no parlor tricks to find, it is bog-standard code...

Code: Select all

int wmain(int argc, wchar_t* argv[])
{
	RAROpenArchiveDataEx OpenArchiveData = {0};

	//
	// Provide file name of first part of multi-part archive.
	// Note, that the file naming scheme is *.001, *.002, *.003, etc...
	//
	OpenArchiveData.ArcNameW = L"x:\\xxx\\Test.001";

	OpenArchiveData.OpenMode = RAR_OM_LIST;

	HANDLE hArcData=RAROpenArchiveEx(&OpenArchiveData);
	if (OpenArchiveData.OpenResult != 0)
	{
		printf("Error opening archive.");
		return 1;
	}

	int count = 0;
	int RHCode,PFCode;
	struct RARHeaderDataEx HeaderData;

	while ((RHCode = RARReadHeaderEx(hArcData, &HeaderData)) == 0)
	{
		++count;
		printf("\n%d: %-20s", count, HeaderData.FileName);
		if ((PFCode = RARProcessFile(hArcData, RAR_SKIP, NULL, NULL)) != 0)
		{
			printf("Error listing archive content.");
			RARCloseArchive(hArcData);
			return 2;
		}
	}

	if (RHCode != ERAR_END_ARCHIVE)
		{
			printf("Error listing archive content.");
			RARCloseArchive(hArcData);
			return 3;
		}

	RARCloseArchive(hArcData);
	return 0;
}

[gdpr deleted 6]

Are they really multi-part RAR files, where a file stretches from one part to the next? Or just single part files with the wrong extension?

Yes, they are really RAR multi-part archives (no split files).
No, not single part files.

[ghisler(Author)]

2elgonzo
I'm already doing this. Unfortunately when I do this with part2 ort part3 file name, I get the same results as when I call it for part1. If I would allow that, the user could select all parts and press Alt+F9 - and for 10 parts, TC will try to unpack the same files 10 times.

Therefore I have to show either just the files starting in that part (older TC versions), or only list all files when the user opens the first part (this is used by TC 8.5 because unrar.dll always returns all files).

[gdpr deleted 6]

2elgonzo
I'm already doing this. Unfortunately when I do this with part2 ort part3 file name, I get the same results as when I call it for part1. If I would allow that, the user could select all parts and press Alt+F9 - and for 10 parts, TC will try to unpack the same files 10 times.

Therefore I have to show either just the files starting in that part (older TC versions), or only list all files when the user opens the first part (this is used by TC 8.5 because unrar.dll always returns all files).

2elgonzo
[snip] or only list all files when the user opens the first part (this is used by TC 8.5 because unrar.dll always returns all files).

Okay, i don't know why TC tries to do backtrack to the 1st part for the ALT+F9 (Unrar.dll doesn't do it), but i actually don't bother about the reasons.

The thing is if you do CTRL+PgDown on such a part, it shows an empty list - even for the first part.

The empty list is not coming from Unrar.dll. Somewhere TC code must decide to not let Unrar.dll enumerate the compressed files, but to show an empty list instead, when you press CTRL+PgDown.


Not knowing the source code of TC, i don't get a grasp on your explanation.

Having a multi-part archive like MyArc.001, MyArc.002, MyArc.003, etc., i can do ALT+F9 on MyArc.001, and it will unpack the whole archive just fine. But when doing CTRL+PgDown on the very same MyArc.001 it only shows an empty list?

[gdpr deleted 6]

2elgonzo
If I would allow that, the user could select all parts and press Alt+F9 - and for 10 parts, TC will try to unpack the same files 10 times.

Actually you do/allow that already. I just tested with TC8.50b5 and TC8.01.

When selecting all parts of a multi-part archive and unpack it with ALT+F9, TC starts with unpacking the first part file - which means it will unpack the whole archive. Then TC continues to unpack the second part file, and you will be confronted with the "File exist, overwrite?" dialog.

And it does that no matter which naming scheme is being used. It happens with naming scheme MyArc.001, MyArc.002, MyArc.003..., as well as with the standard naming scheme MyArc.part1.rar, MyArc.part2.rar, MyArc.part3.rar... From all i can see, TC behaves identical in both cases.

Which makes it a complete mystery to me why you let TC8.50b5 force-show a wrong empty list when doing CTRL+PgDown on MyArc.001.

TC8.01 does not suffer from this silly behaviour, and showed at least the files contained within MyArc.001. (And it did the same when CTRL+PgDown on subsequent parts, while TC8.50b5 insists to show just empty lists.)

[Csimbi]

@elgonzo
Thanks for chipping in, much appreciated trying to help me explain the problem. I hope this finally clarifies the "mystery" bug.

[gdpr deleted 6]

@Ghisler: Thank you!

I just tested with the new TC8.50b6 (both 32-bit and 64-bit), and it handles multi-volume RAR archives with the non-standard naming scheme just fine. It also shows the complete content of the archive, when going into the 1st archive part (which makes not only me, but also Csimbi a happy camper, i guess )

Handling of complete as well as incomplete multi-volume RAR archives is imo now as good as it can be.

[gdpr deleted 6]

This is not a bug report, i just want to inform about a side effect i stumbled upon during testing. The scenario is not really a real-world scenario, and if you would do something like this in real-life, you need to be scolded.

Anyway, for the curious amongst you, here is the side effect and how to reproduce it. Follow the instructions by the letter (including spelling mistakes), do not divert and do not get distracted by your Better Half.

1. 1. Take a multi-part RAR archive of your choice.
   2. Display its content by bringing CTRL+PageDown upon the first part of the archive.
   3. Within the same pane, move one level up (a-ka: out of the archive).
   4. Move all but the first part to some other location (totally harmless). Alternatively, you might delete them instead (mostly harmless; it's not my data anyway ). The first part of the multi-part archive is now sitting there alone.
   5. Bring CTRL+PageDown upon the lonely first part of the archive again.
   6. You will see ... (sorry, i won't give spoilers here )

All in all, this behaviour is not really a big deal. Firstly, you're not going to remove parts of an archive you just want to look into -- that would be nothing short of madness. (Don't look at me!) Secondly, as soon as you try to unpack files from missing parts, TC will ask for the missing parts anyway...

[Csimbi]

@Ghisler: Thank you!

I just tested with the new TC8.50b6 (both 32-bit and 64-bit), and it handles multi-volume RAR archives with the non-standard naming scheme just fine. It also shows the complete content of the archive, when going into the 1st archive part (which makes not only me, but also Csimbi a happy camper, i guess )

Handling of complete as well as incomplete multi-volume RAR archives is imo now as good as it can be.

I confirm that it seems all right now on beta 6; thanks for fixing!
Yes, made me a happy camper

I did not test the side effect you reported; it's unlikely I ever meet such conditions.

[gdpr deleted 6]

... it's unlikely I ever meet such conditions.

If you ever meet such conditions, give me a call. I will enjoy scolding you...