Flat View: Consistent treatment of zip as dirs

Is it possible to make a flat view expand zip archives, e.g. treat zip files as folders in a truly consistent way?

Flat View works within individual archives (i.e. enter an archive, then turn on Flat View and you can see all the files and folders in the archive at one).

Flat View will not show the content of multiple archives from a starting point that is outside of them, however.

But you can use Tools > Find Files to build a list of multiple archive's contents.

Interesting, I didn't know about the Find Files option.

I just realized another inconsistency with handling of zip files that extends into the progress dialog. If I select 100 zip files and select "extract to destination" I get a display of the progress of the current archive being extracted (current file and all files in the current ZIP archive), but I cannot see the total progress, for example number of remaining zip files to be extracted.

I really wish there were more options to customize copy progress in general. I want to see: Progress on current operation, and total progress. I want to see number of files, time estimates, everything! Right now I am not seeing that consistently.

It also bothers me that the progress dialogs are somehow attached to the lister that spawned them, for example they are kept on top of that lister, which does not make any sense to me since they run in their own thread. I understand this might be because they are spawned as a child of the lister, but I believe they should be independent.

I meant to say I want to see:

  • number of files done / total number
  • size done / total size
  • time estimated
  • speed estimate

for current and for all archives that are being extracted.

[ul][li]I think it's wrong to look at the flat view difference as an inconsistency. Folders and archives are very different things, with very different characteristics and performance overheads. Being able to go inside individual archives like folders is a convenience, but that does not make archives the same as folders. They are very different beasts.

One particular difference is that nothing can read or even list any part of an archive if something else is modifying any file within the archive at the same time, and nothing can modify any part of an archive if something else is busy listing or extracting from it. That could make something like flat view problematic if it tried to recurse into multiple archives and monitor them for changes. It could also have large performance issues, since opening and listing archives can be very slow (even more so with some archive formats or compression modes, and even more so when antivirus scanners get involved), and re-listing the whole archive needs to be repeated any time any change is made to the archive if a live view is to be maintained. That's why it makes sense for Find to have an option for this (since it gives you a snapshot, not a live view), but not for flat view. It's also why the Find option is off by default (since it is rarely actually wanted, and can massively slow things down).

[li]The way overall progress is handled for multiple zip files in the same operation is an artifact of the batch extraction process. It's something we could improve, but has remained a low priority. Making it work well would also mean having to open and list all the archives before extraction, and probably re-open them during extraction, which could slow things down in some situations.

[li]Progress dialogs appear on top of the lister that spawned them because it would often be really annoying to lose them. You can however close the lister (doing so won't close the progress dialog), or minimise the progress dialog, or configure the progress dialog to not even appear (and only appear as a button on the jobs bar) if you wish.

[li]Many of the things you're asking for in the progress display are already there in most situations, e.g. copying normal files. Zip extraction may show reduced information, I think due to the way the zip library reports its progress to us. (You should see better reporting for other archive types.) Again, something we may improve but quite a low impact/priority for us vs other things.[/li][/ul]