I need another batch file.

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?

lid wrote:
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-t...-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

lid wrote:
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?

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/tutorial...ry-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/tutorial...rk-folder.html

Paul

On Mon, 02 Jul 2018 18:18:30 -0400, lid wrote:

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.

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

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

"Paul" wrote
|
| Who needs batch skillz, when you have money ?
|
|
http://qa.mythicsoft.com/14676/how-t...-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.

no wrote:

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?

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.

On Mon, 2 Jul 2018 22:14:07 -0500, VanguardLH wrote:

no wrote:

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?

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

Char Jackson wrote:
On Mon, 2 Jul 2018 22:14:07 -0500, VanguardLH wrote:

no wrote:

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?
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

On Tue, 03 Jul 2018 00:29:26 -0400, Paul wrote:

Char Jackson wrote:
On Mon, 2 Jul 2018 22:14:07 -0500, VanguardLH wrote:

no wrote:

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?
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

Char Jackson wrote:
On Tue, 03 Jul 2018 00:29:26 -0400, Paul wrote:

Char Jackson wrote:
On Mon, 2 Jul 2018 22:14:07 -0500, VanguardLH wrote:

no wrote:

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?
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

Char Jackson wrote:

On Mon, 2 Jul 2018 22:14:07 -0500, VanguardLH wrote:

no wrote:

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?

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.

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).

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.

Paul wrote:

Char Jackson wrote:
On Tue, 03 Jul 2018 00:29:26 -0400, Paul wrote:

Char Jackson wrote:
On Mon, 2 Jul 2018 22:14:07 -0500, VanguardLH wrote:

no wrote:

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?
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 ****load of operators mentioned at Help - Search Syntax
that I never knew about. Oh boy, the learning curve just got steep
again.

VanguardLH wrote:
Paul wrote:

Char Jackson wrote:
On Tue, 03 Jul 2018 00:29:26 -0400, Paul wrote:

Char Jackson wrote:
On Mon, 2 Jul 2018 22:14:07 -0500, VanguardLH wrote:

no wrote:

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?
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 ****load 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

On Tue, 3 Jul 2018 02:46:57 -0500, VanguardLH wrote:

Char Jackson wrote:

On Mon, 2 Jul 2018 22:14:07 -0500, VanguardLH wrote:

no wrote:

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?

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.

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.

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.

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.

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.

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.

Yes, I'm aware of that.

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.

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.

Way up above, you said:
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

On Tue, 03 Jul 2018 02:11:42 -0400, Paul wrote:

Char Jackson wrote:
On Tue, 03 Jul 2018 00:29:26 -0400, Paul wrote:

Char Jackson wrote:
On Mon, 2 Jul 2018 22:14:07 -0500, VanguardLH wrote:

no wrote:

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?
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.

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.

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