Opening a rarset only works from part 1

[Thany]

Opening a rarset can only be done from part 1. When opening any subsequent part of the rarset, the file view is completely empty.

Can this be fixed?

[Hacker]

Thany,
TC shows only the files which begin in the opened volume. This is by design.

Roman

[Hacker]

[mod="Hacker"]Moved to the English forum.[/mod]

[Thany]

@Hacker "This is by design" Can the design be changed then please? I suppose you can consider this a feature request then, rather than a bug report.
Or is there a specific reason for only showing files starting at the opened volume? I think it's confusing.

[Hacker]

Thany,
Only the author can answer that.

Roman

[Phred]

Thany,

It's like a book.
The Table of Contents appears in the first few pages. It refers to all the chapters, say, that occupy the body of the book.

You wouldn't expect to find a surprise chapter in the middle of a book when you're flipping through it.
What's listed as the contents of a book is the contents of a book.

It's the same with multi-file rar-sets.
Subsequent .rar files are the contents. The ToCs lies in the 1.rar file.

HTH.

[gdpr deleted 6]

It's the same with multi-file rar-sets.
Subsequent .rar files are the contents. The ToCs lies in the 1.rar file.

Well, that's not correct at all.

Each volume (part) of a multi-volume RAR archive contains a "ToC" of all the files it contains, including partial files (a file whose compressed data is a continuation of a compressed file from the previous volume, and/or a file whose compressed data will "reach" into the next volume). Also, each volume itself is a RAR archive in its own right, as required by the RAR specification; in other words: To extract a file from a volume, no other volume is needed - not even the first, assuming the compressed file data doesn't span multiple volumes. More gory details can be found in the RAR specification: https://www.rarlab.com/technote.htm#arcstruct

That's precisely why the volumes of a multi-volume archive are called volumes.

The book analogue to a multi-volume RAR archive would be a publication made of multiple volumes (books). Each volume (book) has its own ToC about the content it contains, but a volume often doesn't have a ToC for content of the other volumes belonging to the same work. (There are publications where each volume contains the full ToC of the full work across all volumes, though. What can i say, real world is fuzzy )

[Thany]

If the idea is to view only what's in the volume that was opened, then why does it list everything until the end?

If I open part 1 of 20 -> I see contents of parts 1-20
If I open part 6 of 20 -> I see contents of parts 6-20

This doesn't make sense to me. For a rarset (or indeed a 7z set) all volumes belong to the set. In my mind I'm just opening the *set*, not a particular volume. I don't know (or care) what's in a partcular volume, because I don't care how the set is divided up (i.e. which of its contained files go where, etc). It's just a bunch of files to me, that happen to belong together as a single "unit". The fact that they are separate files which can be opened individually, is little more than semantics.

In the end, what matters is what's contained within the entire set, not just the one volume (or even weirder, the one volume until the last). They should be treated as a single indivisble collection of files. Indivisble I say, because throwing away any one of them, breaks the whole set.

[gdpr deleted 6]

If the idea is to view only what's in the volume that was opened, then why does it list everything until the end?

I guess you misread something, because only you articulate this idea of "[only viewing] what's in the volume that was opened", unless i completely missed something here in the topic. As such, there is no answer to be given since the premise of the question is flawed.

Now, the question of why TC only shows the files beginning from the opened volume up to the last volume instead of showing all files contained in the whole volume set (assuming all volumes are present) is a valid one, though.

Also worth mentioning: TC behaves very similar to WinRAR in this regard (with the notable difference of WinRar showing a partial file that is a continuation of a file from the volume prior to the opened one, whereas TC does not show such a partial file), so there is precedence to TC's behavior. And which shouldn't be really surprising either, since TC's unrar functionality essentially relies on unrar.dll from the RAR/WinRAR developer(s).


(Personally, even if i tend to agree with the point you are making, i don't expect TC's behavior to change in the future, due to TC just using unrar.dll more or less as-is. Perhaps there is some packer plug-in that can provide the behavior you are seeking...?)

[ghisler(Author)]

The problem is that the user could select all parts and then try to unpack them. If I listed all files from every part, each file would be unpacked 20 times.

[gdpr deleted 6]

The problem is that the user could select all parts and then try to unpack them. If I listed all files from every part, each file would be unpacked 20 times.

Unfortunately, TC already exhibits that particular problem of trying to unpack files multiple times (regardless of not showing the whole archive content from every volume when navigating into a subsequent volume).

[Thany]

If the idea is to view only what's in the volume that was opened, then why does it list everything until the end?

I guess you misread something, because only you articulate this idea of "[only viewing] what's in the volume that was opened", unless i completely missed something here in the topic. As such, there is no answer to be given since the premise of the question is flawed.

I suppose so then. Whatever. It doesn't matter, it's undesirable behaviour either way.

Also worth mentioning: TC behaves very similar to WinRAR in this regard (with the notable difference of WinRar showing a partial file that is a continuation of a file from the volume prior to the opened one, whereas TC does not show such a partial file), so there is precedence to TC's behavior. And which shouldn't be really surprising either, since TC's unrar functionality essentially relies on unrar.dll from the RAR/WinRAR developer(s).

I think I remember in WinRAR you can open any volume and it'll show the contents of the entire set. I haven't used WinRAR in years though. 7-zip is much nicer. And free.

(Personally, even if i tend to agree with the point you are making, i don't expect TC's behavior to change in the future, due to TC just using unrar.dll more or less as-is. Perhaps there is some packer plug-in that can provide the behavior you are seeking...?)

I have the same fear. But that doesn't mean it's unfixable. I would prefer TC to use the dll from 7-zip, as it's free and works just as well. On top of that, TC could very easily notice that the user has opened part 7, and instead open part 1 behind the scenes.

[Thany]

The problem is that the user could select all parts and then try to unpack them. If I listed all files from every part, each file would be unpacked 20 times.

Why is that a problem? Just unpack from file 1, and skip the rest.
Even so, not having the fix I proposed in my TS doesn't mitigate the problem you describe. Files could easily span multiple volumes, and then what?

Either people shouldn't select all volumes and hit extract, or the extraction mechanism should always start at file 1, and not try to unpack the other files from the same set individually. With my proposal, we can have the best of both.