ANOMALY? Sorting (by size) while a Content: search is in progress

[ChrisGreaves]

Version 1.5.0.1383a (x64)

Code: Select all

t: ext:doc !content: count:200

Untitled.png (65.9 KiB) Viewed 8184 times

I am searching my T: data partition for MSWord documents, of which I have 16,000+ on the drive. Yes, I know that there are better ways.
I have not yet reached my cut-off point of a count of 200 items.
I think "What's the smallest size (bytes) Document that I have found so far?", so I click on the SIZE column heading to sort the list.

And Everything re-starts the search (Querying...1 items, Querying...2 items, Querying...3 items, ...)

I'd prefer that Everything went on searching, adding items to the foot of a sorted list.

When a list is sorted, a view from the top is a good starting point.
Of course I think of Everything as having an internal list of DOCument files which it processes in a serial fashion, but that list of files need not change. After the current partial-Result list is sorted, Everything could continue to work through its internal file list and append new entries to the rear of the sorted list, thereby rendering it un-sorted until the next Sort request on a column header.
Perhaps the right-hand end of the status bar could be cleared to indicate that now, the result list is not really in a sorted sequence?

I've been telling people for years that I am a new user, so I may have misunderstood something here.
Thanks, Chris

[therube]

To start, it is the count: that is causing the re-start.
The count: is going to limit your results to (up to) 200 of (potentially) 16,000 files.

I guess what is happening is when you change your sort order, (initial) count: is then set back to '0', as the (ordered) list of file has changed. If you remove count:, you can interactively sort.

So I'm thinking, depending on what you're looking to do, what information you're trying to get out of it, you need to let it finish, first, then sort afterwards. And then if you only want 200 items, select 200 of them.
(You could also Index content:, not that I'm sure what that entails?)


(What is !content: finding? Appears that a .doc that only includes a picture is considered !content:, when in fact it does have 'content', just not 'doc', i.e., textual content, necessarily.)

[ChrisGreaves]

TheRube>>> To start, it is the count: that is causing the re-start.

Hi therube. If the count is causing the restart then I think that is a bug; “Count:200” in the search command is setting an upper limit on the size of the result list. “Count:200” says “Stop adding items to the result list WHEN you reach 200 items in the result list.
Everything should (but in my post I suggested could/should) continue appending items to that result list after it had sorted the result list (by Size) before continuing looking for files that satisfied the other constraints (“T:”, “ext:doc” and so on).


TheRube>>> The count: is going to limit your results to (up to) 200 of (potentially) 16,000 files.

Agreed.

TheRube>>> I guess what is happening is when you change your sort order, (initial) count: is then set back to '0', as the (ordered) list of file has changed. If you remove count:, you can interactively sort.

As above. I can’t see why the search has to restart. When I click on the column heading for Size, I am asking Everything to “please sort these in as/descending sequence by size (and then carry on searching for files and adding them to the list).
The results that are already in the result list don’t change, because there is no need for Everything to go back to the start of ITS internal file list and test those files already tested. Just pause for a second, sort the existing display, then carry on with the search. Pause, but don’t stop – until you have 200 items in the result list.

TheRube>>> So I'm thinking, depending on what you're looking to do, what information you're trying to get out of it, you need to let it finish, first, then sort afterwards. And then if you only want 200 items, select 200 of them.

By “finish” I think you mean “until you reach 200 items”, and this I could do. But if I can sort the list while it is being built, I get data (knowledge of the smallest Size: found so far) and can think about that while Everything continues its slow search for the files (on disk)

TheRube>>> (You could also Index content:, not that I'm sure what that entails?)

It means a faster search, but I have not indexed content. Right now I am still trying to get some results, any results. I can make the search more efficient once I have seen the Content: function performing in my quest to find “devoid of content” documents and/or workbooks.

TheRube>>> (What is !content: finding? Appears that a .doc that only includes a picture is considered !content:, when in fact it does have 'content', just not 'doc', i.e., textual content, necessarily .)

Right now Content: is finding files that are 2 MB in size, loaded with text AND images.
Something is not quite right yet,

@VOID you may want to hold off replying for a day or two. Right now I am making a clone of my hard drive partition T: to an SSD external drive on the grounds that that may save me execution time with the OnDisk Content: searches. Fighting a bush fire on two fronts!

Cheers, Chris

[void]

Thank you for your post ChrisGreaves,

I'd prefer that Everything went on searching, adding items to the foot of a sorted list.

I have put high on my TODO list to not requery when there is a query in progress.
Thank you for the suggestion.

Currently, Everything is designed to requery on sort when using count:

[ChrisGreaves]

I have put high on my TODO list to not requery when there is a query in progress.

Void, thanks for this response. I am not sure that it needs to be put high on the list; low would suit me fine.
I was not sure whether I had misunderstood what was going on, hence "Anomaly" rather than "Bug".
As a bug it has gone undetected for a long time, so I suspect I am the only one who was disturbed by it!
Now that I know of it as a bug, I can work around it.
Cheers, Chris