Hack to return additional info properties from ES.exe

[Etienne]

I would like to return additional columns from es.exe than the ones it is capable of giving.
I am posting because some may be interested in my solution to this problem, and for a little guidance in implementing it.

I am producing a script to act as a wrapper around es.exe to solve this problem: The information I'd like to return(or an index to it) can be embedded in a filelist that is queried by es.exe from the wrapper.
For example, I successfully exported a filelist containing many extra columns. Then I created a copy of it with each row's size column replaced with the byte offset of the start of that row. then this "hacked" copy was used as the filelist to query with ES.
The 'hacked' size column for each item returned from es is used by the wrapper to retrieve and display all the columns of original source filelist document. This mostly worked, but the bug in this design is it doesn't work for folders, because the size column is always calculated for folders.

I'm thinking of using the run count column instead to ameliorate this - my question is, what is the allowed maximum values for the run count column? Or is there a way i can keep everything from using calculated values for the size of folders? Or would you suggest using a different column to "hack"?
I could also keep an integer index to a database, but i would prefer to continue to keep the reference as byte offsets to the csv filelist.
Other possible solutions considered are appending the information to the file's name or including fake sub files for every folder, and having the wrapper obtain the correct information for folders from there.
Thanks

[therube]

I manually set the Run Count for a file (in Run History.csv) to 65536, "ran" it a couple of times, & it incremented its' count.
Now just how high... ?

[Etienne]

I discovered the max value for a run-count:4294967295
However, there's a bug where items with that run-count will not be returned from a run-count:4294967295 search -
so the practical limit seems to be 4294967294.
Which is large enough to assign a unique run-count to each file to use an index.

If paired with the date-run, which can also be returned from es.exe, the set of unique (date-run, run-count) combinations
becomes essentially limitless for all practical purposes.

[dldc114]

Hello, how is the current performance? Does the system tend to slow down or freeze when there are a large number of files?

[void]

4294967295 (0xffffffff) not displaying in ES is a bug.
This value shows correctly in Everything.
I have put this on my things to fix list.
Thanks for the issue report.

Hello, how is the current performance? Does the system tend to slow down or freeze when there are a large number of files?

Performance of what?
ES query performance? -ES uses WM_COPYDATA (shared memory) and named pipes.
ES shouldn't be slowing the system. WM_COPYDATA has a maximum size of 2GB, if you are approaching this limit in low memory environment you might see other programs paged to disk, slowing the system..

[void]

ES-1.1.0.33 will now correctly show 4294967295 values for run count.