Since DO13 can use Everything in various ways, e.g. calculating folder sizes or find files, this raises one or two questions.
ET can be set up to omit certain files or to not index files and folders at all. This means if DO uses ET for calculating folder sizes, this may be not accurate when ET does not index all files within this folder, correct?
So how does DO decide to use or not to use ETs API? Or with others words: How can I be sure that certain information, provided by ET, is up to date and correct at all?
Opus asks Everything if it has a drive/folder indexed. If it says yes, and Opus is configured to use Everything for sizes, then Opus will report the size Everything says the folder is.
You can override how size calculation is done within specific folders (or path wildcards), via Preferences / Folders / Folder Sizes:
OK, that's my understanding, too, so far. As assumed, if not all files are indexed by ET, e.g temporary ones, because not needed, those file sizes won't be recognised by DO neither?
I'm not sure to be honest. Everything may still index the size of the folder itself separately, but I don't know. Jon may know better when he's around.
Everything doesn't index folder sizes, instead we ask it for the contents of the folder via a search filter and add the returned sizes up. Not as efficient as it could be but still a lot quicker than recursively reading the directory.
So if some files are omitted from the index and not returned by Everything then the folder size would probably be incorrect. Honestly I didn't know Everything had that ability so we didn't consider it might be an issue.
Give it a try and see if that is indeed what happens, and if so we'll have to see if there's anything we can do about it (probably it would just mean disabling the folder size calculation if we can identify that files have been omitted).
So, this might be a game changer. If ET does index folder sizes independently of any filters or omitted result sets, DO probably will get the correct folder sizes as well.
OTH, this is may be true for folder sizes.
DO13 obviously can use ET for search results, too. I have the impression that any (ET) exclusion filters are valid for DO, too, since those filters do modify ET indexes.
Or with other words: DO will see only files and folders, that ET has indexed before(?) This has to be taken intk account if DO does not find a file, when ETs index does not provide it (if DO is configured using ET of course)
Semi on-topic: it would be nice, to also have faster file count column population, similar to the EFS folder sizes. I have only one important folder, the photo folder, but at the moment the file counting takes a minute or so for over 1500 folders.
That is correct: Everything will report folder sizes based on the indexed files/folders.
Don't exclude any files/folders in Everything
(Instead, define a default filter in Everything that excludes these files/fodlers. Or, when using version 1.5, use Result Omission)
In Everything 1.4, folder indexing needs to be enabled manually (as shown by @lxp) as it costs a bit of performance to keep folder sizes up-to-date. Not that I ever noticed any performance issues when enabled, btw.
Everything 1.5 is faster than 1.4 so here folder indexing is enabled by default.
Not sure what you mean with "exclusion filters", but Filters (menu:Search => Organize Filters) do not impact the reported folder size.
Should be possible already more or less.
The SDK has Everything_GetTotFileResults and Everything_GetTotFolderResults. With a search "c:\some folder\" it will report the total amount of foilders and files in that folder, including subfolders.
But will be easier once the SDK gets updated ...
There is another thing to consider regarding folder sizes:
Everything scans local NTFS volumes on a low level and therefor 'sees' more files and fodlers than a filemanager does, for example the Home directory of other users and some Windows folders.
Those will be included in the reported folder sizes.
(FWIW: These files will not be reported in search results as Opus will remove them from the list during 'post-processing' for showing in Lister).
My personal opinion regarding folder sizes:
Folder sizes reported by any tool should be used as just a rough indication. Modern filesystems got too complicated to give correct results.
Some examples:
No tool I know of takes Alternate (/Named) Data Streams (ADS) into account. A 1KB file can have several 1GB datastreams. Reported size will still be 1KB
Should Directory Symbolic Links and Folder Junctions be "followed" or not? One day you would want it to, the other day you won't.
Hardlinks: a file can have multiple names (like C:\Windows\System32\notepad.exe and C:\Windows\notepad.exe) while being stored on disc only once. What size should be reported for C:\windows?
(Fun fact: Different Windows versions report different Size on Disk values for the exact same file ...)
I think for a Folder Size column in Opus, a rough estimate is enough to get a quick impression. When you want exact values (OK, more or less; see above) press 'ALT + ENTER' on a folder and let Windows calculate what it thinks it is.
Is this still on the TODO list as calculating folder sizes still takes a long time in Opus 40 beta for me with Everything 1.5a and folder sizes indexed (eg. Users folder size takes ages when viewing C:) ?
With Everything, all folders sizes shown instantly.
It’s still on the list. Folder sizes should appear quickly with it without it though. See the gif in the release notes for example; none of the gifs are sped up or modified (other than to fix my own misclicks while recording :)).
