CLI > ES > Get "Total Number of Files" (or folders) on a volume?

[AgentSam]

QUESTION

Is it possible to use the CLI-utility, ES, to simply get the "total number of files" (or folders, or both) on a specified volume?

After looking at: https://www.voidtools.com/support/every ... interface/

I was unable to spot any options related to this. I was searching for something similar to:

Code: Select all

es -count-files "C:\"

OUTRO

Any help or nudge in the right direction greatly appreciated.

[void]

es -get-result-count "C:\"

-get-result-count

[AgentSam]

SOLVED (MOSTLY)

Exactly what I was looking for. I don't know how I missed that! Argh! My page search should have yielded that, but -- oh well; developer to the rescue.

FEELING POSITIVE

It's amazing how "complete" the implementation of Everything appears to be. There's just almost everything, one could hope for. Even the ability to have bookmarks in subfolders (that was one of the "hidden INI-options" I was happy to discover just the other day).

FILE COUNTS -- IN POWERSHELL

OK, so, just to be clear... The ES CLI-interface makes use of the same settings as the Everything Service, right? So that means, any excluded folders, perhaps also hidden or system files, will not be included in the "result count"?

For example, on my TEMP-drive, when I run the following in powershell:

Code: Select all

(Get-ChildItem -Path "T:\" -Recurse -File -Force -ErrorAction SilentlyContinue | Measure-Object).Count

I get a "total file count" of: 64204

The PowerShell script counts every single file on the T:\ drive, including hidden files, system files, and files within all folders and subfolders. The count is comprehensive and includes absolutely everything except empty directories.

RESULT COUNTS -- in ES

When I run the same in ES:

Code: Select all

es -get-result-count "T:\"

I get a "total result count" of: 75580

So, the result count returned by ES is, apparently, HIGHER than the actual number of files on the drive. What could be the reason for this, assuming that the commands were issued within a second of each other, and no new files were created between the given commands.

I would have assumed, that the result returned by ES might actually be LOWER, if some TEMP folders were excluded, but I'm seeing the opposite. Hmmz.

EDIT/UPDATE -- ADDITIONAL TESTING DONE

OK, so yea, I modified the powershell command, by removing the "-File" option, so it should now return the absolute total count, including empty folders:

Code: Select all

(Get-ChildItem -Path "T:\" -Recurse -Force -ErrorAction SilentlyContinue | Measure-Object).Count

And the "total" was: 75615

This is much closer to what ES was reporting, so -- the takeway, I must remember to clean up my temp folders completely from time to time. The number of empty folders left in there can get pretty high.

[AgentSam]

Sidenote: I'm so tired of how every new post and even a minor edit to an existing post causes this:

• This post is not visible to other users until it has been approved by a moderator.

Yea, just great... been a developer on multiple forums for about 35 years and still treated like a newbie on every new platform. If it wasn't so understandable for eliminating spam, this would be insulting.

[therube]

Recently ran into a "count" (total number of files) difference, Comparison File List.

I used (UNIX) find (command) on a directory tree, & it found exactly the same number of "files" that Everything found.

Now, searches in each need to be "compatible", succinct enough that unintended files are not counted... (like your -File in your original PS search).
If you output the searches of each program, you can then compare them & find where the differences are...

[AgentSam]

Recently ran into a "count" (total number of files) difference... searches in each need to be "compatible", succinct enough that unintended files are not counted... [snip]

Yea, 100% -- it can sometimes be a bit tricky matching result between multiple different tools, each with their own configs, inclusion/exclusion options, etc.. But, my original issue of getting the result count has been solved.

However, I want to thank you for bringing FFS to my attention (via the link to the other discussion thread over at the FFS-forums). I was not even aware of that tool! Looks useful, and it's Open Source. Awesome!