I have a similar 'problem' that seems to be related.
The folder 'Google Drive A', is shown as having 1366 files and 168 folders:
But, when I open that folder to see the subfolders, the counts in the 'Files (total)' column add up to over 40,000 files, and the counts in the 'Folders (total)' add up to a few thousand folders (partial screenshot below):
I find it odd and inconsistent that in the first example, each archive is counted as a single file, and in the second example, the archive is handled like a folder which includes many files.
When I receive a photo and video collection from a client, I take an inventory, but unless I use a calculator to add up the numbers shown, I can't get an accurate inventory unless I extract everything from archives first.
Since the number of files in each archive is visible (as in the second screenshot), I seems logical that if more than one archive is in a folder such as my 'Google Drive A' folder that the 'Files (total)' count for Google Drive A reflect the numbers I see in the second screenshot.
Archives are considered a single file, unless you're looking at the archive itself. What you're seeing there is normal and expected behavior.
While you could have a column which counted files inside archives (and archives in archives, etc.) when totalling folder contents, it would be very slow. That's part of why it isn't done by default. The other part is that people don't usually expect to see a count of archive contents when measuring the number of files in a folder.
The Windows Properties dialogs are exactly the same here. They won't count files inside archives when counting what's in a folder. Each archive is only one file. That's how archives work.
We could make things "consistent" by showing nothing at all for archives, but we figure the information is wanted if you've turned those columns on in a folder that has archives directly below it.
Leo,
You assumed I did not understand that an archive is considered a single file. I understand they are are considered a single file, so when I see the number of files the parent folder contains (1 for each archive) that is expected behavior.
You wrote, "nor is it unexpected", but when I open the folder and view the archives inside it, I see the number of 'files' the archived folders contain, which is unexpected behavior.
So, although I do really like being able to see the number of 'files' in an archive, I understand it's not technically accurate.
Anyhow, this is not a feature request, I was only pointing out an inconsistency in case it was related to ZipD's issue. Since it is not, I'm sorry I bothered you with this.
If seeing that information instead of nothing at all is unexpected then I guess we could make Opus not show any counts at all next to archives... I'm not sure that would be an improvement, though.
Including archive content counts as part of higher-level folder counts would not make sense in general. It could be provided as a separate column, but I think it would be so slow that it wouldn't be used very often.
So I think the way things behave now makes perfect sense. The extra info is there when it's requested, in a place that would otherwise not show any information at all, but it isn't being added to other counts where it doesn't belong and most people would not expect it to be. And the expensive calculation isn't being done recursively, where it could take up significant time and (for some archive formats) resources.
There is never going to be absolute consistency when it comes to archives. They are both files and folders at the same time. Which one they are treated as depends on context.
The issue in the root post is one where the Print/Export dialog isn't picking up / triggering calculation of the extra data for archives. That is most likely a bug, since the data should appear in the print/export output, next to the archive it is related to, the same as it does in the file display.
(It's possible there's a reason it's blocked in the Print/Export dialog, but I think it's probably an oversight. Need to look at the code in detail to be sure, but have not had a chance yet.)
