I need another batch file.

Post by n***@none.invalid
I want to search more than directory on multiple drives for movie
files.
I would like to copy a title to the clipboard and pass it to a batch
file that will give me a hit if I get a match.
I have no batch file skillz.
Anyone care to write one for me?

Who needs batch skillz, when you have money ?

http://qa.mythicsoft.com/14676/how-to-search-in-specific-sub-subfolders-in-agent-ransack

"That functionality is not available in Agent Ransack.
However, in FileLocator Pro you can do it using a location filter, e.g.

Look In: C:\Folder;+important
"

Paul

Mayayana

2018-07-02 23:54:52 UTC

"Paul" <***@needed.invalid> wrote
|
| Who needs batch skillz, when you have money ?
|
|
http://qa.mythicsoft.com/14676/how-to-search-in-specific-sub-subfolders-in-agent-ransack
|
| "That functionality is not available in Agent Ransack.
| However, in FileLocator Pro you can do it using a location filter,
e.g.
|
| Look In: C:\Folder;+important
| "

Or just use Agent Ransack. When looking for file
names it searches very quickly. Any kind of
script or BAT is probably going to take longer
because AR is working at a lower level.

Agent Ransack is using kernel functions like
FindFirstFile, FindNextFile. A script or BAT will
probably use the same methods, but 2 or 3
times removed.

Custom code is only useful when one needs
to do a custom operation, like picking 12 songs
and writing them to CD, 100 times over.

Diesel

2018-07-09 22:43:54 UTC

Post by n***@none.invalid
I want to search more than directory on multiple drives for movie
files.
I would like to copy a title to the clipboard and pass it to a
batch file that will give me a hit if I get a match.
I have no batch file skillz.
Anyone care to write one for me?

Who needs batch skillz, when you have money ?
http://qa.mythicsoft.com/14676/how-to-search-in-specific-sub-subfol
ders-in-agent-ransack
"That functionality is not available in Agent Ransack.
However, in FileLocator Pro you can do it using a location filter, e.g.
Look In: C:\Folder;+important
"
Paul

You can do it for free with dirlister, the console, etc... [g]

--
To prevent yourself from being a victim of cyber
stalking, it's highly recommended you visit here:
https://tekrider.net/pages/david-brooks-stalker.php
===================================================
The best teddy bears are the live kind.

Paul

2018-07-02 23:05:15 UTC

Since we're in the Win7 group, it's also
possible you could define a custom "Library"
to bring all the folders under one roof.

https://www.sevenforums.com/tutorials/583-new-library-create.html

At the bottom of the page, will be other relevant
articles for working with your new library.

Then, in your (free) search tool, simply point it
at the Library.

A Library has a Default Folder. If you "drop" a file
onto a Library, it's stored in the Default Folder.
If you intended the file to go to Disk6\Movies, then
open Explorer to Disk6\Movies and put it in the
individual folder you wanted to use. The file will
then still show up in a search of that Library.

Some of the articles have important info at the
top of the page. For example, see the green
Information text at the top of this one.

https://www.sevenforums.com/tutorials/4617-libraries-include-network-folder.html

Paul

Char Jackson

2018-07-02 23:16:33 UTC

It looks like Agent Ransack will already do what you need.
-search more than [ONE] directory - yes
-on multiple drives - yes
-for movie files - yes, by providing multiple file extensions
-write search results to a file - yes

Post by n***@none.invalid
I have no batch file skillz.
Anyone care to write one for me?

I'm not sure that you need one. What do you want it to do?

--
Char Jackson

VanguardLH

2018-07-03 03:14:07 UTC

Why not use a file search tool?

Search Everything from voidtools
Builds a database of filenames only (no contents of files). Very fast.

FileLocator Lite (aka Agent Ransack)
Can search on title and/or contents in files. Slow on first search
since it actually has to do a search instead of building up a filename
cache. Just as fast as Everything on 2nd and subsequent searches
(performed within the same instance of FileLocator) because it builds a
temporary cache. Its cache is discarded when you exit the program.

Just copy the title as you intended into the clipboard and then paste
into the search field in either of the above two programs.

Char Jackson

2018-07-03 04:10:02 UTC

Why not use a file search tool?
Search Everything from voidtools
Builds a database of filenames only (no contents of files). Very fast.
FileLocator Lite (aka Agent Ransack)
Can search on title and/or contents in files. Slow on first search
since it actually has to do a search instead of building up a filename
cache. Just as fast as Everything on 2nd and subsequent searches
(performed within the same instance of FileLocator) because it builds a
temporary cache. Its cache is discarded when you exit the program.

Mini-hijack: When I do a baseline search of my data drive, the search
completes in 59 seconds. If I immediately do the same search again, from
the same instance of Agent Ransack, it takes 42 seconds. The 3rd, 4th,
and 5th searches each also take 42 seconds.

So subsequent searches are definitely faster, but how can I make
subsequent searches take 0 seconds, as they do with Everything? Is there
a setting I've missed?

--
Char Jackson

Paul

2018-07-03 04:29:26 UTC

Why not use a file search tool?
Search Everything from voidtools
Builds a database of filenames only (no contents of files). Very fast.
FileLocator Lite (aka Agent Ransack)
Can search on title and/or contents in files. Slow on first search
since it actually has to do a search instead of building up a filename
cache. Just as fast as Everything on 2nd and subsequent searches
(performed within the same instance of FileLocator) because it builds a
temporary cache. Its cache is discarded when you exit the program.

Mini-hijack: When I do a baseline search of my data drive, the search
completes in 59 seconds. If I immediately do the same search again, from
the same instance of Agent Ransack, it takes 42 seconds. The 3rd, 4th,
and 5th searches each also take 42 seconds.
So subsequent searches are definitely faster, but how can I make
subsequent searches take 0 seconds, as they do with Everything? Is there
a setting I've missed?

The System Read Cache is likely a block cache,
which means attempts to access a file, still go
through the file stack. And that activity is a
bottleneck. Depending on what you're doing, you
might see 4K to 10K operations per second. On
one RAM based file system on Linux, you can hit
190K operations per second, as a comparison.

The best behavior happened in Win2K. The
concept was in its most pure form then,
at introduction. This was to match the read
cache on SunOS/Solaris, and MacOSX later.
Win2K was the third big platform to get it.
It's been watered down with later OSes.

Windows also had an interrupt limiter, intended
to make the system responsive (but a bit slow),
if an "interrupt storm" happened. And that number
is in the 10K to 15K per second range. I don't know
if that is auto-tuned, or has been changed for
Windows 10 or not.

It *is* possible to use third-party caching code.
Historically, a couple hardware manufacturers have
provided such a beast, but compatibility isn't always
that good with such things. I think Intel got tired
of supporting theirs, even though recently they've
tinkered with the same sort of silly ideas with their
XPoint products and Xeon. A lab outside North
America did that implementation for Intel.

Of course it will never be faster than Everything.exe,
but there is room for improvement...

Paul

Char Jackson

2018-07-03 05:01:52 UTC

Why not use a file search tool?
Search Everything from voidtools
Builds a database of filenames only (no contents of files). Very fast.
FileLocator Lite (aka Agent Ransack)
Can search on title and/or contents in files. Slow on first search
since it actually has to do a search instead of building up a filename
cache. Just as fast as Everything on 2nd and subsequent searches
(performed within the same instance of FileLocator) because it builds a
temporary cache. Its cache is discarded when you exit the program.

Mini-hijack: When I do a baseline search of my data drive, the search
completes in 59 seconds. If I immediately do the same search again, from
the same instance of Agent Ransack, it takes 42 seconds. The 3rd, 4th,
and 5th searches each also take 42 seconds.
So subsequent searches are definitely faster, but how can I make
subsequent searches take 0 seconds, as they do with Everything? Is there
a setting I've missed?

The System Read Cache is likely a block cache,
which means attempts to access a file, still go
through the file stack. And that activity is a
bottleneck. Depending on what you're doing, you
might see 4K to 10K operations per second. On
one RAM based file system on Linux, you can hit
190K operations per second, as a comparison.
The best behavior happened in Win2K. The
concept was in its most pure form then,
at introduction. This was to match the read
cache on SunOS/Solaris, and MacOSX later.
Win2K was the third big platform to get it.
It's been watered down with later OSes.
Windows also had an interrupt limiter, intended
to make the system responsive (but a bit slow),
if an "interrupt storm" happened. And that number
is in the 10K to 15K per second range. I don't know
if that is auto-tuned, or has been changed for
Windows 10 or not.
It *is* possible to use third-party caching code.
Historically, a couple hardware manufacturers have
provided such a beast, but compatibility isn't always
that good with such things. I think Intel got tired
of supporting theirs, even though recently they've
tinkered with the same sort of silly ideas with their
XPoint products and Xeon. A lab outside North
America did that implementation for Intel.
Of course it will never be faster than Everything.exe,
but there is room for improvement...

I think I figured it out. Everything shows results as you type, so the
results are provided in 0 seconds whether it's a first search or a
subsequent search. So 0 seconds, or real time, is the benchmark. With
Agent Ransack, on 7, 8.1, and 10, if I do a search that initially takes
3 seconds, subsequent searches will report "<1 secs", which is
indistinguishable from Everything's results. Bottom line, to make Agent
Ransack give me results as quickly as Everything does, I have to make
sure the initial search is about 3 seconds or less. That's usually
pretty hard to do.

VanguardLH makes it seem more universal than that, so perhaps I'm still
missing something.

--
Char Jackson

Paul

2018-07-03 06:11:42 UTC

Why not use a file search tool?
Search Everything from voidtools
Builds a database of filenames only (no contents of files). Very fast.
FileLocator Lite (aka Agent Ransack)
Can search on title and/or contents in files. Slow on first search
since it actually has to do a search instead of building up a filename
cache. Just as fast as Everything on 2nd and subsequent searches
(performed within the same instance of FileLocator) because it builds a
temporary cache. Its cache is discarded when you exit the program.

Mini-hijack: When I do a baseline search of my data drive, the search
completes in 59 seconds. If I immediately do the same search again, from
the same instance of Agent Ransack, it takes 42 seconds. The 3rd, 4th,
and 5th searches each also take 42 seconds.
So subsequent searches are definitely faster, but how can I make
subsequent searches take 0 seconds, as they do with Everything? Is there
a setting I've missed?

The System Read Cache is likely a block cache,
which means attempts to access a file, still go
through the file stack. And that activity is a
bottleneck. Depending on what you're doing, you
might see 4K to 10K operations per second. On
one RAM based file system on Linux, you can hit
190K operations per second, as a comparison.
The best behavior happened in Win2K. The
concept was in its most pure form then,
at introduction. This was to match the read
cache on SunOS/Solaris, and MacOSX later.
Win2K was the third big platform to get it.
It's been watered down with later OSes.
Windows also had an interrupt limiter, intended
to make the system responsive (but a bit slow),
if an "interrupt storm" happened. And that number
is in the 10K to 15K per second range. I don't know
if that is auto-tuned, or has been changed for
Windows 10 or not.
It *is* possible to use third-party caching code.
Historically, a couple hardware manufacturers have
provided such a beast, but compatibility isn't always
that good with such things. I think Intel got tired
of supporting theirs, even though recently they've
tinkered with the same sort of silly ideas with their
XPoint products and Xeon. A lab outside North
America did that implementation for Intel.
Of course it will never be faster than Everything.exe,
but there is room for improvement...

I think I figured it out. Everything shows results as you type, so the
results are provided in 0 seconds whether it's a first search or a
subsequent search. So 0 seconds, or real time, is the benchmark. With
Agent Ransack, on 7, 8.1, and 10, if I do a search that initially takes
3 seconds, subsequent searches will report "<1 secs", which is
indistinguishable from Everything's results. Bottom line, to make Agent
Ransack give me results as quickly as Everything does, I have to make
sure the initial search is about 3 seconds or less. That's usually
pretty hard to do.
VanguardLH makes it seem more universal than that, so perhaps I'm still
missing something.

But doesn't Everything cheat, by starting up at boot
time ? It then has time to read in its index files.
Check and see what the RAM footprint of Everything.exe
looks like, when configured to support the multiple
partitions on your system.

The time for Everything to make its first search,
has to "pay" for disk read time of the index files.

*******

And I just checked the System Read cache on Win2K,
and it appears to check 25K files per second.
It took Agent Ransack about four seconds to
search C: over and over again. The drive is
slow, and the first search took a lot longer.
The little time display on Agent Ransack
said the search took "<1 second", but sorry,
that's bull. It's taking 4 seconds to paint the
screen with a half dozen located items. And at
that time, the System Read cache is "warmed up".

Paul

VanguardLH

2018-07-03 08:08:24 UTC

Why not use a file search tool?
Search Everything from voidtools
Builds a database of filenames only (no contents of files). Very fast.
FileLocator Lite (aka Agent Ransack)
Can search on title and/or contents in files. Slow on first search
since it actually has to do a search instead of building up a filename
cache. Just as fast as Everything on 2nd and subsequent searches
(performed within the same instance of FileLocator) because it builds a
temporary cache. Its cache is discarded when you exit the program.

Mini-hijack: When I do a baseline search of my data drive, the search
completes in 59 seconds. If I immediately do the same search again, from
the same instance of Agent Ransack, it takes 42 seconds. The 3rd, 4th,
and 5th searches each also take 42 seconds.
So subsequent searches are definitely faster, but how can I make
subsequent searches take 0 seconds, as they do with Everything? Is there
a setting I've missed?

The System Read Cache is likely a block cache,
which means attempts to access a file, still go
through the file stack. And that activity is a
bottleneck. Depending on what you're doing, you
might see 4K to 10K operations per second. On
one RAM based file system on Linux, you can hit
190K operations per second, as a comparison.
The best behavior happened in Win2K. The
concept was in its most pure form then,
at introduction. This was to match the read
cache on SunOS/Solaris, and MacOSX later.
Win2K was the third big platform to get it.
It's been watered down with later OSes.
Windows also had an interrupt limiter, intended
to make the system responsive (but a bit slow),
if an "interrupt storm" happened. And that number
is in the 10K to 15K per second range. I don't know
if that is auto-tuned, or has been changed for
Windows 10 or not.
It *is* possible to use third-party caching code.
Historically, a couple hardware manufacturers have
provided such a beast, but compatibility isn't always
that good with such things. I think Intel got tired
of supporting theirs, even though recently they've
tinkered with the same sort of silly ideas with their
XPoint products and Xeon. A lab outside North
America did that implementation for Intel.
Of course it will never be faster than Everything.exe,
but there is room for improvement...

I think I figured it out. Everything shows results as you type, so the
results are provided in 0 seconds whether it's a first search or a
subsequent search. So 0 seconds, or real time, is the benchmark. With
Agent Ransack, on 7, 8.1, and 10, if I do a search that initially takes
3 seconds, subsequent searches will report "<1 secs", which is
indistinguishable from Everything's results. Bottom line, to make Agent
Ransack give me results as quickly as Everything does, I have to make
sure the initial search is about 3 seconds or less. That's usually
pretty hard to do.
VanguardLH makes it seem more universal than that, so perhaps I'm still
missing something.

But doesn't Everything cheat, by starting up at boot
time ? It then has time to read in its index files.
Check and see what the RAM footprint of Everything.exe
looks like, when configured to support the multiple
partitions on your system.
The time for Everything to make its first search,
has to "pay" for disk read time of the index files.
*******
And I just checked the System Read cache on Win2K,
and it appears to check 25K files per second.
It took Agent Ransack about four seconds to
search C: over and over again. The drive is
slow, and the first search took a lot longer.
The little time display on Agent Ransack
said the search took "<1 second", but sorry,
that's bull. It's taking 4 seconds to paint the
screen with a half dozen located items. And at
that time, the System Read cache is "warmed up".
Paul

Yep. Run services.msc and you'll find a service named "Everything". I
mentioned that in my prior reply to Char. Everything emulates the
Windows Search service: it is a duplication of Windows Search. However,
Everything search more places by default and generally seems faster at
building its database.

Of course, you can configure Windows Search to scan more places to
effectively cover the same ones as Everything. You can even configure
Windows Search to scan inside the files.

To add more places for Windows Search to catalog:
Control Panel -> Indexing Options -> Modify

To have Windows Search scan inside files:
Control Panel -> Indexing Options -> Advanced -> File Types tab
Select "Index Properties and File Contents".

Even Everything does not search everywhere, by default. Some users will
complain Everything won't find something they know to exist -- until
those users configure Everything to look more places.

The problem with any Microsoft search tool is that Microsoft
deliberately encodes them to NOT find certain folders or files. You can
use a command shell and can see a folder or file using the 'dir' command
(perhaps with the /ahsr switch) but Windows Search refuses to list that
folder or file. Those are "special" files (said with the inflection of
the Church Lady) and Microsoft thinks users shouldn't see them. That's
what first led me to find Agent Ransack (which later got renamed to
FileLocator to have a more professional name once the author started
getting some paid commercial licenses rolling in): to find files that
Windows would hide (even with enabling to show system files). I could
see it right there but Windows keep pretending it didn't exist.

By the way, Everything *can* search inside of files to find content.
It's just not the default behavior. If you use the "content:" search
operative, Everything will look inside files; however, it doesn't cache
any of that content, so content search is s-l-o-w, just like it is slow
in FileLocator. I just found out about the content: operative, so
Everything might indeed supplant my having FileLocator installed for
that function. Entering "*.txt" will be super fast but to search on
content, like "*.txt content:studio" (there are some Visual Studio .txt
files on my drive) results with the "querying ..." showing for a lot
longer until it has completed looking in all *.txt files for the string.
While faster than FileLocator on FileLocator's first run, the same
content search in FileLocator was just as speedy as Everything.

There's a whole shitload of operators mentioned at Help -> Search Syntax
that I never knew about. Oh boy, the learning curve just got steep
again.

Paul

2018-07-03 08:28:56 UTC

Why not use a file search tool?
Search Everything from voidtools
Builds a database of filenames only (no contents of files). Very fast.
FileLocator Lite (aka Agent Ransack)
Can search on title and/or contents in files. Slow on first search
since it actually has to do a search instead of building up a filename
cache. Just as fast as Everything on 2nd and subsequent searches
(performed within the same instance of FileLocator) because it builds a
temporary cache. Its cache is discarded when you exit the program.

Mini-hijack: When I do a baseline search of my data drive, the search
completes in 59 seconds. If I immediately do the same search again, from
the same instance of Agent Ransack, it takes 42 seconds. The 3rd, 4th,
and 5th searches each also take 42 seconds.
So subsequent searches are definitely faster, but how can I make
subsequent searches take 0 seconds, as they do with Everything? Is there
a setting I've missed?

The System Read Cache is likely a block cache,
which means attempts to access a file, still go
through the file stack. And that activity is a
bottleneck. Depending on what you're doing, you
might see 4K to 10K operations per second. On
one RAM based file system on Linux, you can hit
190K operations per second, as a comparison.
The best behavior happened in Win2K. The
concept was in its most pure form then,
at introduction. This was to match the read
cache on SunOS/Solaris, and MacOSX later.
Win2K was the third big platform to get it.
It's been watered down with later OSes.
Windows also had an interrupt limiter, intended
to make the system responsive (but a bit slow),
if an "interrupt storm" happened. And that number
is in the 10K to 15K per second range. I don't know
if that is auto-tuned, or has been changed for
Windows 10 or not.
It *is* possible to use third-party caching code.
Historically, a couple hardware manufacturers have
provided such a beast, but compatibility isn't always
that good with such things. I think Intel got tired
of supporting theirs, even though recently they've
tinkered with the same sort of silly ideas with their
XPoint products and Xeon. A lab outside North
America did that implementation for Intel.
Of course it will never be faster than Everything.exe,
but there is room for improvement...

I think I figured it out. Everything shows results as you type, so the
results are provided in 0 seconds whether it's a first search or a
subsequent search. So 0 seconds, or real time, is the benchmark. With
Agent Ransack, on 7, 8.1, and 10, if I do a search that initially takes
3 seconds, subsequent searches will report "<1 secs", which is
indistinguishable from Everything's results. Bottom line, to make Agent
Ransack give me results as quickly as Everything does, I have to make
sure the initial search is about 3 seconds or less. That's usually
pretty hard to do.
VanguardLH makes it seem more universal than that, so perhaps I'm still
missing something.

But doesn't Everything cheat, by starting up at boot
time ? It then has time to read in its index files.
Check and see what the RAM footprint of Everything.exe
looks like, when configured to support the multiple
partitions on your system.
The time for Everything to make its first search,
has to "pay" for disk read time of the index files.
*******
And I just checked the System Read cache on Win2K,
and it appears to check 25K files per second.
It took Agent Ransack about four seconds to
search C: over and over again. The drive is
slow, and the first search took a lot longer.
The little time display on Agent Ransack
said the search took "<1 second", but sorry,
that's bull. It's taking 4 seconds to paint the
screen with a half dozen located items. And at
that time, the System Read cache is "warmed up".
Paul

Yep. Run services.msc and you'll find a service named "Everything". I
mentioned that in my prior reply to Char. Everything emulates the
Windows Search service: it is a duplication of Windows Search. However,
Everything search more places by default and generally seems faster at
building its database.
Of course, you can configure Windows Search to scan more places to
effectively cover the same ones as Everything. You can even configure
Windows Search to scan inside the files.
Control Panel -> Indexing Options -> Modify
Control Panel -> Indexing Options -> Advanced -> File Types tab
Select "Index Properties and File Contents".
Even Everything does not search everywhere, by default. Some users will
complain Everything won't find something they know to exist -- until
those users configure Everything to look more places.
The problem with any Microsoft search tool is that Microsoft
deliberately encodes them to NOT find certain folders or files. You can
use a command shell and can see a folder or file using the 'dir' command
(perhaps with the /ahsr switch) but Windows Search refuses to list that
folder or file. Those are "special" files (said with the inflection of
the Church Lady) and Microsoft thinks users shouldn't see them. That's
what first led me to find Agent Ransack (which later got renamed to
FileLocator to have a more professional name once the author started
getting some paid commercial licenses rolling in): to find files that
Windows would hide (even with enabling to show system files). I could
see it right there but Windows keep pretending it didn't exist.
By the way, Everything *can* search inside of files to find content.
It's just not the default behavior. If you use the "content:" search
operative, Everything will look inside files; however, it doesn't cache
any of that content, so content search is s-l-o-w, just like it is slow
in FileLocator. I just found out about the content: operative, so
Everything might indeed supplant my having FileLocator installed for
that function. Entering "*.txt" will be super fast but to search on
content, like "*.txt content:studio" (there are some Visual Studio .txt
files on my drive) results with the "querying ..." showing for a lot
longer until it has completed looking in all *.txt files for the string.
While faster than FileLocator on FileLocator's first run, the same
content search in FileLocator was just as speedy as Everything.
There's a whole shitload of operators mentioned at Help -> Search Syntax
that I never knew about. Oh boy, the learning curve just got steep
again.

Actually, you cannot stop Windows Search from indexing content.

Doesn't matter what that little control claims :-)
I already tested this and was disappointed by the result.

I don't know if Microsoft ever bothered to fix it. I'm not
going to sit around re-testing it.

It's like Henry Ford telling you that you can have any
color of car you want, as long as it's painted black.
There's a philosophical statement inherent in this
from the Windows Search developers that says "of
course you *always* index content, no exceptions".
So that tick box is probably their little in-joke.

Paul

Mayayana

2018-07-03 12:35:44 UTC

"Paul" <***@needed.invalid> wrote

| Actually, you cannot stop Windows Search from indexing content.
|

Why not? Indexing service is one of the first
things I turn off. I don't see any point to all that
disk thrashing just to provide faster search. And
I never use Windows search, anyway.

I think this was discussed before. Everything.exe
indexes while Agent Ransack just does a fast
search. I find AR nearly instant for most of what
I search for, but maybe it depends on personal style.
If Char waits nearly 1 minute just to find a matching
file name he must have an awfully lot of files. I don't
wait that long to find embedded text in a file. On
the other hand, I'm never searching C drive because
I don't store things there.

Everything.exe might be best for people who don't
tend to be organized, and AR for people who don't
depend so much on search.

VanguardLH

2018-07-03 17:36:04 UTC

Post by Paul
Actually, you cannot stop Windows Search from indexing content.

I don't remember discussing stopping Windows Search but maybe. I
haven't had my coffee yet and my concentration is impaired by a sore
body after felling and cutting up yet another tree destroyed by
carpenter ants (so I had to spray insecticide when cutting the trunk).

In any case, yes, you can stop it. Got into services.msc and either
stop the service (for that Windows session) or disable it (to never run
again until you reenable the service).

Rather than permanently disable it, you can remove it: Control Panel ->
Programs and Features -> Turn Windows features on or off (and wait) ->
scroll down and deselect Windows Search. I leave Windows Search running
because of its integration with the Start menu's search box and also in
MS Outlook. I have also added more places for where it will scan.

While Microsoft has a rather large vocabulary of operators you can use
in its searches, it's their proprietary list. Since I've learned regex
for several programs, I prefer to use that to narrow my searches. Both
Everything and FileLocator support regex.

Post by Paul
Doesn't matter what that little control claims :-) I already tested
this and was disappointed by the result.

Of what little control do you speak?

Post by Paul
I don't know if Microsoft ever bothered to fix it. I'm not going to
sit around re-testing it.

I've never had a problem disabling the Windows Search service or
removing the feature from Windows.

Post by Paul
There's a philosophical statement inherent in this from the Windows
Search developers that says "of course you *always* index content, no
exceptions". So that tick box is probably their little in-joke.

Are you talking about right-clicking on a drive in Windows Explorer and
disabling Windows Search from scanning that drive? After deselecting
"Allow files on this drive to have contents indexed in addition to file
properties", and after rebuilding the index, anytime that I've performed
a Windows Search the files on those drives aren't found. I have a disk
where local copies of backups are stored (amonst other places) and I
don't need those files indexed. I have a disk where I save downloads
(for installs), some much smaller backups (like exported settings for
programs), some ISO image files of CDs (e.g., Windows 7, Office 365),
and other files that are reproducible and have their own online backups,
so I don't need those files indexed.

Char Jackson

2018-07-03 10:05:28 UTC

Why not use a file search tool?
Search Everything from voidtools
Builds a database of filenames only (no contents of files). Very fast.
FileLocator Lite (aka Agent Ransack)
Can search on title and/or contents in files. Slow on first search
since it actually has to do a search instead of building up a filename
cache. Just as fast as Everything on 2nd and subsequent searches
(performed within the same instance of FileLocator) because it builds a
temporary cache. Its cache is discarded when you exit the program.

Mini-hijack: When I do a baseline search of my data drive, the search
completes in 59 seconds. If I immediately do the same search again, from
the same instance of Agent Ransack, it takes 42 seconds. The 3rd, 4th,
and 5th searches each also take 42 seconds.
So subsequent searches are definitely faster, but how can I make
subsequent searches take 0 seconds, as they do with Everything? Is there
a setting I've missed?

The System Read Cache is likely a block cache,
which means attempts to access a file, still go
through the file stack. And that activity is a
bottleneck. Depending on what you're doing, you
might see 4K to 10K operations per second. On
one RAM based file system on Linux, you can hit
190K operations per second, as a comparison.
The best behavior happened in Win2K. The
concept was in its most pure form then,
at introduction. This was to match the read
cache on SunOS/Solaris, and MacOSX later.
Win2K was the third big platform to get it.
It's been watered down with later OSes.
Windows also had an interrupt limiter, intended
to make the system responsive (but a bit slow),
if an "interrupt storm" happened. And that number
is in the 10K to 15K per second range. I don't know
if that is auto-tuned, or has been changed for
Windows 10 or not.
It *is* possible to use third-party caching code.
Historically, a couple hardware manufacturers have
provided such a beast, but compatibility isn't always
that good with such things. I think Intel got tired
of supporting theirs, even though recently they've
tinkered with the same sort of silly ideas with their
XPoint products and Xeon. A lab outside North
America did that implementation for Intel.
Of course it will never be faster than Everything.exe,
but there is room for improvement...

I think I figured it out. Everything shows results as you type, so the
results are provided in 0 seconds whether it's a first search or a
subsequent search. So 0 seconds, or real time, is the benchmark. With
Agent Ransack, on 7, 8.1, and 10, if I do a search that initially takes
3 seconds, subsequent searches will report "<1 secs", which is
indistinguishable from Everything's results. Bottom line, to make Agent
Ransack give me results as quickly as Everything does, I have to make
sure the initial search is about 3 seconds or less. That's usually
pretty hard to do.
VanguardLH makes it seem more universal than that, so perhaps I'm still
missing something.

I have Everything set to run as a service, so yes, of course, it's
preloaded, but I'm not asking about that. I'm asking about VLH's claim
that Agent Ransack can be just as fast as Everything on subsequent
searches. So far, I've been unable to duplicate that here. I'm hoping
he'll lay it out and clue me in.

Post by Paul
The time for Everything to make its first search,
has to "pay" for disk read time of the index files.

I'm asking about Agent Ransack, not Everything.

--
Char Jackson

VanguardLH

2018-07-03 07:46:57 UTC

Why not use a file search tool?
Search Everything from voidtools
Builds a database of filenames only (no contents of files). Very fast.
FileLocator Lite (aka Agent Ransack)
Can search on title and/or contents in files. Slow on first search
since it actually has to do a search instead of building up a filename
cache. Just as fast as Everything on 2nd and subsequent searches
(performed within the same instance of FileLocator) because it builds a
temporary cache. Its cache is discarded when you exit the program.

Like I said, File Locator (aka Agent Ransack) builds a filename cache on
its first run, so each subsequent search is lightning fast. On the
other hand, Everything works like Windows Search in scanning the drive
even when not using it to build a database it uses for its search. You
don't notice the background database build by Everything, so the first
search in Everything is lightning fast.

Alas, quite often I need to find something *in* a file, especially
because I don't know what the file is named. Filelocator can search
inside. Everything cannot.

Of course, you can also configure the Windows Search service to not only
search on filenames but also on their contents. Updating the index will
take a LOT longer and its database will be a LOT bigger. If all you
need is to find by filename, you can also modify where Windows Search
will scan for files (beyond its minimal defaults).

Post by Char Jackson
So subsequent searches are definitely faster, but how can I make
subsequent searches take 0 seconds, as they do with Everything? Is there
a setting I've missed?

Everything builds its database in the background. It also catches file
I/O activity while it is active (and it always is since it runs as a
service). It knows when a file is created, deleted, or modified the
moment it happens and updates its database to immediately reflect the
change.

FileLocator will cache up the folder timestamps along with filenames on
its first run. On subsequent runs within the same instance of
FileLocator, it can skip any folders whose timestamps have not changed.
Since the folder hasn't changed, no files within the folder have
changed. But FileLocator isn't constantly monitoring the system calls
for file I/O to instantly detect and record file changes. Not until
FileLocator performs the 2nd, or later, searches can it detect if a
folder has changed its timestamp from a prior scan. It still has to
traverse the folder tree looking for changed folders.

I haven't timed FileLocator when doing content searches. I suppose it
could keep a hash of each file on the first run, and in subsequent runs
on files in changed folders, to see if the file has changed its hash --
or on a size change since that would be a much faster check via file I/O
calls than rehashing a file to check against a prior stored hash of a
file. However, a file could change in content but not change in size.
A byte is a byte no matter what character it represents and why I first
thought a hash of a file might get cached to detect if content changed.

Everything will always be much faster than FileLocator. Everything only
searches on filenames. It runs constantly in the background just like
Windows Search to keep indexing the files while you are doing something
else. It immediately catches changes (adds, deletes, renames) to
filenames. To search on content, use FileLocator; however, the only
time it access the file system is when it performs a search meaning it
still has to walk through the file system.

Everything runs as an indexing service (like Windows Search).
FileLocator is a user-mode process you load when you want to use it.

Char Jackson

2018-07-03 10:00:00 UTC

Why not use a file search tool?
Search Everything from voidtools
Builds a database of filenames only (no contents of files). Very fast.
FileLocator Lite (aka Agent Ransack)
Can search on title and/or contents in files. Slow on first search
since it actually has to do a search instead of building up a filename
cache. Just as fast as Everything on 2nd and subsequent searches
(performed within the same instance of FileLocator) because it builds a
temporary cache. Its cache is discarded when you exit the program.

Like I said, File Locator (aka Agent Ransack) builds a filename cache on
its first run, so each subsequent search is lightning fast.

Actually, that's why I jumped in. I don't see that behavior here on
Windows 7, 8.1, or 10. Subsequent searches in Agent Ransack are faster
than initial searches, but still very far from "lightning fast".

In my test described above, the initial search times for Everything and
Agent Ransack were 0 seconds and 59 seconds, respectively. Subsequent
searches took 0 seconds and 42 seconds, respectively. Unless I'm
misunderstanding, I think you're saying that subsequent searches in
Agent Ransack can also be 0 seconds, or very close to it. So far, I can
only force that behavior by drastically restricting Ransack's search
scope, so I must be missing something.

Post by VanguardLH
On the
other hand, Everything works like Windows Search in scanning the drive
even when not using it to build a database it uses for its search. You
don't notice the background database build by Everything, so the first
search in Everything is lightning fast.

Yes, I'm aware of how Everything works. What I'm wondering is why Agent
Ransack is still dog slow on subsequent searches. You're saying it's not
slow for you, so I'm thinking I missed a setting or something.

Post by VanguardLH
Alas, quite often I need to find something *in* a file, especially
because I don't know what the file is named. Filelocator can search
inside. Everything cannot.

I'm aware of that. I very rarely need to search inside a file.
Interestingly, when I use Agent Ransack, it's almost always to find
something by its filename, a scenario where Everything would actually be
better suited.

Post by VanguardLH
Of course, you can also configure the Windows Search service to not only
search on filenames but also on their contents. Updating the index will
take a LOT longer and its database will be a LOT bigger. If all you
need is to find by filename, you can also modify where Windows Search
will scan for files (beyond its minimal defaults).

I think everyone will agree that Windows Search is not playing in the
same ball game as Agent Ransack and Everything. Let's ignore that thing.

Post by Char Jackson
So subsequent searches are definitely faster, but how can I make
subsequent searches take 0 seconds, as they do with Everything? Is there
a setting I've missed?

Yes, I'm aware of that.

Post by VanguardLH
FileLocator will cache up the folder timestamps along with filenames on
its first run. On subsequent runs within the same instance of
FileLocator, it can skip any folders whose timestamps have not changed.
Since the folder hasn't changed, no files within the folder have
changed. But FileLocator isn't constantly monitoring the system calls
for file I/O to instantly detect and record file changes. Not until
FileLocator performs the 2nd, or later, searches can it detect if a
folder has changed its timestamp from a prior scan. It still has to
traverse the folder tree looking for changed folders.

Right, so is that an acknowledgement that Agent Ransack is not
significantly faster on subsequent searches? If so, then my instance of
Agent Ransack is, unfortunately, working as expected.

Post by VanguardLH
I haven't timed FileLocator when doing content searches. I suppose it
could keep a hash of each file on the first run, and in subsequent runs
on files in changed folders, to see if the file has changed its hash --
or on a size change since that would be a much faster check via file I/O
calls than rehashing a file to check against a prior stored hash of a
file. However, a file could change in content but not change in size.
A byte is a byte no matter what character it represents and why I first
thought a hash of a file might get cached to detect if content changed.
Everything will always be much faster than FileLocator. Everything only
searches on filenames. It runs constantly in the background just like
Windows Search to keep indexing the files while you are doing something
else. It immediately catches changes (adds, deletes, renames) to
filenames. To search on content, use FileLocator; however, the only
time it access the file system is when it performs a search meaning it
still has to walk through the file system.
Everything runs as an indexing service (like Windows Search).
FileLocator is a user-mode process you load when you want to use it.

Yes, I'm aware of all of that.

Post by VanguardLH
FileLocator Lite (aka Agent Ransack)
Can search on title and/or contents in files. Slow on first search
since it actually has to do a search instead of building up a filename
cache. Just as fast as Everything on 2nd and subsequent searches
(performed within the same instance of FileLocator) because it builds a
temporary cache. Its cache is discarded when you exit the program.

The part I'm currently unable to duplicate here is the claim that
"[Agent Ransack is] just as fast as Everything on 2nd and subsequent
searches". For me, on 3 Windows OS versions, I can't even get close to
that. Do you know what I might be missing?

--
Char Jackson

VanguardLH

2018-07-03 17:45:40 UTC

Why not use a file search tool?
Search Everything from voidtools
Builds a database of filenames only (no contents of files). Very fast.
FileLocator Lite (aka Agent Ransack)
Can search on title and/or contents in files. Slow on first search
since it actually has to do a search instead of building up a filename
cache. Just as fast as Everything on 2nd and subsequent searches
(performed within the same instance of FileLocator) because it builds a
temporary cache. Its cache is discarded when you exit the program.

Like I said, File Locator (aka Agent Ransack) builds a filename cache on
its first run, so each subsequent search is lightning fast.

Maybe because I'm using an SSD for the Windows and app drive that
FileLocator's subsequent runs looks just as fast to me. Maybe there is
a difference where FileLocator is slower on its cached runs than
Everything but I doubt I'll notice a fraction of a second difference.
On an HDD, especially a slow one (like a blue instead of black WDC
disk), it would be noticeable.

Post by Char Jackson
In my test described above, the initial search times for Everything and
Agent Ransack were 0 seconds and 59 seconds, respectively. Subsequent
searches took 0 seconds and 42 seconds, respectively. Unless I'm
misunderstanding, I think you're saying that subsequent searches in
Agent Ransack can also be 0 seconds, or very close to it. So far, I can
only force that behavior by drastically restricting Ransack's search
scope, so I must be missing something.

FileLocator will still have to scan the file system to check for folder
timestamp changes to determine if any files under them have changed. It
still has to do a lot of file I/O. Everything is monitoring file
changes as they happen. That's why I said Everything, as an indexing
service, will be faster than FileLocator even on FileLocator's cached
searches. However, on an SSD, that file system scan in FileLocator on
its cached search is so fast that I cannot see it taking longer than
Everything.

Char Jackson

2018-07-03 23:01:07 UTC

Why not use a file search tool?
Search Everything from voidtools
Builds a database of filenames only (no contents of files). Very fast.
FileLocator Lite (aka Agent Ransack)
Can search on title and/or contents in files. Slow on first search
since it actually has to do a search instead of building up a filename
cache. Just as fast as Everything on 2nd and subsequent searches
(performed within the same instance of FileLocator) because it builds a
temporary cache. Its cache is discarded when you exit the program.

Like I said, File Locator (aka Agent Ransack) builds a filename cache on
its first run, so each subsequent search is lightning fast.

Nope, that's not it. I use SSD's here, as well, and the difference
between Everything and Ransack on first runs versus subsequent runs
isn't a fraction of a second. Using the numbers I provided above,
Everything provided results in 0 and 0 seconds, while Ransack provided
results in 59 and 42 seconds. You'd definitely notice the difference
between 0 and 42 seconds.

The only way to get Ransack to operate as fast as Everything is to
severely constrain the test; i.e, ask both to search a very shallow
directory tree with relatively few files. That's not a valid test,
though, so I think the conclusion has to be that your claim is provably
false.

--
Char Jackson

VanguardLH

2018-07-04 02:52:17 UTC

Why not use a file search tool?
Search Everything from voidtools
Builds a database of filenames only (no contents of files). Very fast.
FileLocator Lite (aka Agent Ransack)
Can search on title and/or contents in files. Slow on first search
since it actually has to do a search instead of building up a filename
cache. Just as fast as Everything on 2nd and subsequent searches
(performed within the same instance of FileLocator) because it builds a
temporary cache. Its cache is discarded when you exit the program.

Like I said, File Locator (aka Agent Ransack) builds a filename cache on
its first run, so each subsequent search is lightning fast.

Nope, that's not it. I use SSD's here, as well, and the difference
between Everything and Ransack on first runs versus subsequent runs
isn't a fraction of a second. Using the numbers I provided above,
Everything provided results in 0 and 0 seconds, while Ransack provided
results in 59 and 42 seconds. You'd definitely notice the difference
between 0 and 42 seconds.
The only way to get Ransack to operate as fast as Everything is to
severely constrain the test; i.e, ask both to search a very shallow
directory tree with relatively few files. That's not a valid test,
though, so I think the conclusion has to be that your claim is provably
false.

Guess that depends on how many files can be found matching on your
search criteria. For me, there are only 903 *.txt files. FileLocator
took 9 seconds on a 2nd (cached) search, not 42 seconds. I don't
remember what I searche on in my 1st reply.

Char Jackson

2018-07-04 04:40:27 UTC

Why not use a file search tool?
Search Everything from voidtools
Builds a database of filenames only (no contents of files). Very fast.
FileLocator Lite (aka Agent Ransack)
Can search on title and/or contents in files. Slow on first search
since it actually has to do a search instead of building up a filename
cache. Just as fast as Everything on 2nd and subsequent searches
(performed within the same instance of FileLocator) because it builds a
temporary cache. Its cache is discarded when you exit the program.

Like I said, File Locator (aka Agent Ransack) builds a filename cache on
its first run, so each subsequent search is lightning fast.

Nope, that's not it. I use SSD's here, as well, and the difference
between Everything and Ransack on first runs versus subsequent runs
isn't a fraction of a second. Using the numbers I provided above,
Everything provided results in 0 and 0 seconds, while Ransack provided
results in 59 and 42 seconds. You'd definitely notice the difference
between 0 and 42 seconds.
The only way to get Ransack to operate as fast as Everything is to
severely constrain the test; i.e, ask both to search a very shallow
directory tree with relatively few files. That's not a valid test,
though, so I think the conclusion has to be that your claim is provably
false.

Guess that depends on how many files can be found matching on your
search criteria. For me, there are only 903 *.txt files.

The number of matching files is mostly irrelevant. What's more important
is the total number of files and the total number of directories that
needed to be traversed.

Post by VanguardLH
FileLocator
took 9 seconds on a 2nd (cached) search, not 42 seconds. I don't
remember what I searche on in my 1st reply.

Heh, the 42 seconds was on my system, not yours. :-)

--
Char Jackson

VanguardLH

2018-07-04 16:32:24 UTC

FileLocator took 9 seconds on a 2nd (cached) search, not 42 seconds.
I don't remember what I searche on in my 1st reply.

Heh, the 42 seconds was on my system, not yours. :-)

Yep, 9 seconds on mine, 42 seconds on yours, but probably different
search criteria in file systems with different numbers of folders and
files. While probably not exactly the same folder and file count as
FileLocator must traverse when reading the file system, a 'dir /s'
command (which takes a LOT longer probably due to all the stdout)
returns 223,765 files and 138,371 folders (and just over an additional
thousand each for a 'dir /ahs'). I didn't bother looking at the depth
of the folders.

My SSD is a Samsung 850 EVO 2.5" 256MB SATA3. Different SSDs have
different read/write speeds. Alas, this is in an old desktop PC that
only has SATA2 ports on the mobo. No SATA3 yet (that'll be in my next
build). This was a salvaged PC built in 2009 that I got in 2013 that
required a new PSU, new video card (which still pricey these days), a
new HDD (later added the SSD), and Speedfan for the CPU fan since the
BIOS could no longer control RPM based on temperature. The 8 GB RAM it
has is the max this old mobo will support. Most times about half is
unused. Hey, it was free (but not to repair).

The only setting that I found in FileLocator that looks like it could
change its search speed is under Tools -> Configuration -> General ->
Performance -> Allow multiple search threads. The description says it
will create seaparate threads for each CPU core. While I don't consider
my CPU as recent or powerful (Intel Core 2 Quad 9400), it is a quad
core, so maybe that helps.

Something else that could affect search speed is security software. I
was using Avast free (trimmed down to just the file, behavior, and web
shields - no fluff, no lureware). I uninstalled it, ran aswclear, and
cleaned out all its remnant registry entries and files. I tried
Bitdefender free but found it noticeably impacted file operations. Most
everything got slower. Web browsing was most affected where web
browsers got jerky or longer delay to respond when scrolling long web
pages and downloads took longer. When starting to download a file, it
was like 5-10 seconds before even the browser dialog appeared to let me
select where to save the file. Went back to Avast and everything was
faster to respond. In the interim between uninstalling Avast but before
installing Bitdefender, I noticed my system seemed a tad perkier. I
realize all that interrogation causes overhead but some security
software causes more impact on responsiveness than others.

Now that I found Everything has a "content:" operator to look inside of
files (although a lot slower but still seems faster than FileLocator),
I'll probably not bother using FileLocator anymore. FileLocator let me
dig into files looking for strings but I found out so does Everything.
I'll have to spend some time digging into all the operators available in
Everything (see Help -> Search Syntax) along with all the command-line
options (Help -> Command Line Options).

Mayayana

2018-07-03 12:46:33 UTC

"VanguardLH" <***@nguard.LH> wrote

| Alas, quite often I need to find something *in* a file, especially
| because I don't know what the file is named. Filelocator can search
| inside. Everything cannot.
|
| Of course, you can also configure the Windows Search service to not only
| search on filenames but also on their contents.

One of the reasons I stopped using Windows search was
because it would only look inside certain types of files. It
so happens that CAB files contain a plain text list of the
contained files. I rarely need to search for a file by name,
but needing to find a file in a CAB is not so unusual.
If I need to find something like abc.dll among 60 system
CABs in a service pack or on a Windows install disk, I can
do that quickly by seaching for the text "abc.dll" in the
CABs, using Agent Ransack.

Windows search categorizes a CAB as a "binary" file
and considers text search irrelevant. So you can't search
for files in CABs. VersionInfo or resource strings in PE
files, or EXIF tags in JPG are a similar case.

VanguardLH

2018-07-03 18:22:32 UTC

Post by Mayayana
| Alas, quite often I need to find something *in* a file, especially
| because I don't know what the file is named. Filelocator can search
| inside. Everything cannot.
|
| Of course, you can also configure the Windows Search service to not only
| search on filenames but also on their contents.
One of the reasons I stopped using Windows search was because it would
only look inside certain types of files. It so happens that CAB files
contain a plain text list of the contained files. I rarely need to
search for a file by name, but needing to find a file in a CAB is not
so unusual. If I need to find something like abc.dll among 60 system
CABs in a service pack or on a Windows install disk, I can do that
quickly by seaching for the text "abc.dll" in the CABs, using Agent
Ransack.
Windows search categorizes a CAB as a "binary" file and considers
text search irrelevant. So you can't search for files in CABs.
VersionInfo or resource strings in PE files, or EXIF tags in JPG are
a similar case.

Control Panel -> Indexing Options -> Advanced -> File Types tab

You don't see a list of filetypes there that have an associated handler
that you can choose whether or not to include in Windows Search? It
won't search for contents on filetypes for which no handler has been
assigned because then it has no means of looking in the file. For me,
all filetypes available with a handler (so the only ones listed) are
selected. CAB is one of the filetypes listed.

For me, Peazip is the handler associated with .cab files. I don't know
what handler (program) you use to open .cab files. I can see why
Windows Search doesn't look in compressed archive files. Does
Everything search /inside/ of .zip files? I just did a test. I created
a .txt file with a long string that should be unique. I zipped up the
.txt file into a .zip file. Everything could instantly find the new zip
file with a search on "*.zip". It took over 55 seconds (how long
depends on how many .zip files you have to look inside) for Everything
to run "*.zip content:nowisthetimeforallgoodmentocometotheaid" to find
the particular .zip file with the unique string. If I exit Everthing's
window (not its service) and reperform the search on zip files with
content of the unique string, it again takes 55 seconds to find the
particular .zip file. So Everything will look inside compressed files
but only it you direct it to, but the search results are not cached
across multiple runs of the Everything GUI.

Did you ever configure the Windows Search service to look inside of
files? Control Panel -> Indexing Options -> Advanced -> Filetypes tab,
enable the "Index Properties and File Contents" option (and rebuild the
index)? As with Everything taking a lot longer in its search on
contents, Windows Search will take a long time to dig into files. Be
interesting to find out if "and File Contents" would make Windows Search
dig into compressed files.

Mayayana

2018-07-03 22:05:56 UTC

"VanguardLH" <***@nguard.LH> wrote

| > Windows search categorizes a CAB as a "binary" file and considers
| > text search irrelevant. So you can't search for files in CABs.
| > VersionInfo or resource strings in PE files, or EXIF tags in JPG are
| > a similar case.
|
| Control Panel -> Indexing Options -> Advanced -> File Types tab
|

Interesting. That must be a Win7 addition. I
haven't looked at Windows search to speak of
since I chased away that obnoxious dog cartoon
in XP. I don't know why anyone would use it.

Diesel

2018-07-09 22:43:54 UTC