Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.mac.advocacy > #136485
| From | Paul <nospam@needed.invalid> |
|---|---|
| Newsgroups | alt.comp.os.windows-10, comp.sys.mac.advocacy, alt.comp.os.windows-11 |
| Subject | Re: It is stunning when you see how badly Windows operates: indexing |
| Date | 2025-08-12 13:41 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <107fubq$3el5o$1@dont-email.me> (permalink) |
| References | (7 earlier) <107c1lq$27jk$1@nnrp.usenet.blueworldhosting.com> <107c285$2c32t$1@dont-email.me> <107dckr$2nolj$7@dont-email.me> <107eim1$32gtq$1@dont-email.me> <107fo2v$3bn97$3@dont-email.me> |
Cross-posted to 3 groups.
On Tue, 8/12/2025 11:54 AM, Alan wrote:
> In summary:
>
> You claimed that moving a file generated a deletefile entry and a createfile entry in the USN journal...
>
> ...and you've just shown that to be bullshit.
I regret to inform you, that the output of this utility
is NOT THE SAME AS THE OTHER TIME I RAN IT.
For example, previously, as a file was written, there were incremental
size events recorded for some reason. Those are missing from the trace now.
Can you imagine ? An OS first released in 2015 and it is now 2025,
and something has changed ? While the NTFS API revision number has
not changed, the design of the file system has changed and is not
backward compatible (max cluster size in W10 can't be mounted by Win7).
The fsutil utility is an instance of utility that parses journal entries.
There is no guarantee it is good or better than other examples of parsers
written to analyze the thing.
The point is, unless a single journal event has sufficient
self-contained metadata for some calculus, there won't be any calculus.
They're not going to sift through the events in there, until they
have enough to perform some magic.
I tried an experiment this morning, to make it more efficient,
and what that did, is take an all day run to index C: and reduce
that to two hours or so. It did not speed up all that much, and
the inverted index file was still large. I tried searching for
all images on the Test Machine with width:>0
and it reported 75000 images but then it kinda froze (the progress
bar on it stopped moving).
It's just clunky software, and as I indicated before, nobody here
particular cares about it or cares for it, using third-party
tools instead which are more predictable. Sometimes you get
lucky with the federated search and it works quickly, but it could
take many indexing tries before it settles down. Originally, it exhibited
looping behavior, where the count of files would go up and down by
1 file count (keeping the CPU working on it). My working instance
of it (Windows 7), is not looping like that now.
I would be a lot happier, if I could tell you how to turn it off,
but Microsoft is using it for some purpose of their own, and it
could only be stopped by removing executables and moves of that sort.
There is no button to switch it off, or I'd have switched it off on
most of my installs here by now. If you kill it in Task Manager
("SearchIndexer.exe"), it restarts, and it does not follow a three strikes
rule either, it will just keep restarting, with variable intervals
for the restart. The restart time can be as short as one second.
Or as long as minutes.
This is why it's not a fetish topic, it is not reliable enough for
daily use, and other tools work when you use them.
The inverted index design is not all that unusual. I got my first
taste of one of those on Adobe Distiller 4 late in Win98. It has
an inverted index for searching PDF files, and it uses the
merge small sets of files into the Master Index method too, once
the index gets to a certain size. And the Adobe indexer was also
dreadfully slow. The Microsoft behavior is not all that different.
There are other kinds of databases for storing filenames, that
are going to be a lot faster than an inverted content index
(which is what an Everything.exe or a File Locator Pro would use).
Even when the index is told to not store content, it still
stores the metadata as if it was content (the size of the index
file doesn't exactly get smaller).
*******
Since the playback journal works hand in glove with file system recovery,
if the recovery method changes, what is collected in the journal has to match.
That is one purpose it has to meet. The design would change, in the same
way as other things changed, to reduce wear on SSD drives. That's why some
of this evolution is going on.
A secondary purpose is for broadcasting file changes to utilities for file tracking purpose.
As an example of another change, the file buffering on file handles changed,
such that writes are buffered to 64K and the writer will not write just one
cluster when one cluster is ready. If the file is closed, then any remaining
material in the buffer is flushed. I first noticed this on a fragmenter tool.
At one time, it would make 4K fragments for me. Then on a later OS, it would
only make 64K fragments (and the code for that utility had not changed).
There are constantly changes like this going on in the OS, without
anyone being informed of it. You make observations as best you can,
to keep track.
Paul
Back to comp.sys.mac.advocacy | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-08-09 16:30 -0700
Re: It is stunning when you see how badly Windows operates: indexing Hank Rogers <Hank@nospam.invalid> - 2025-08-09 18:55 -0500
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-08-09 17:08 -0700
Re: It is stunning when you see how badly Windows operates: indexing Hank Rogers <invalid@nospam.com> - 2025-08-10 03:22 +0000
Re: It is stunning when you see how badly Windows operates: indexing Paul <nospam@needed.invalid> - 2025-08-09 23:52 -0400
Re: It is stunning when you see how badly Windows operates: indexing "David B." <BD@hotmail.co.uk> - 2025-08-10 09:54 +0100
Re: It is stunning when you see how badly Windows operates: indexing Paul <nospam@needed.invalid> - 2025-08-09 23:28 -0400
Re: It is stunning when you see how badly Windows operates: indexing "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2025-08-10 12:34 +0800
Re: It is stunning when you see how badly Windows operates: indexing Paul <nospam@needed.invalid> - 2025-08-10 11:25 -0400
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-08-10 12:37 -0700
Re: It is stunning when you see how badly Windows operates: indexing Paul <nospam@needed.invalid> - 2025-08-10 19:46 -0400
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-08-10 17:00 -0700
Re: It is stunning when you see how badly Windows operates: indexing Paul <nospam@needed.invalid> - 2025-08-11 00:04 -0400
Re: It is stunning when you see how badly Windows operates: indexing Marion <marion@facts.com> - 2025-08-11 06:13 +0000
Re: It is stunning when you see how badly Windows operates: indexing Hank Rogers <invalid@nospam.com> - 2025-08-11 06:23 +0000
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-08-11 11:26 -0700
Re: It is stunning when you see how badly Windows operates: indexing Paul <nospam@needed.invalid> - 2025-08-12 01:15 -0400
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-08-12 08:54 -0700
Re: It is stunning when you see how badly Windows operates: indexing Paul <nospam@needed.invalid> - 2025-08-12 13:41 -0400
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-08-12 10:54 -0700
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-08-11 10:57 -0700
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-08-12 08:52 -0700
Re: It is stunning when you see how badly Windows operates: indexing "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2025-08-11 20:22 +0800
Re: It is stunning when you see how badly Windows operates: indexing Marion <marion@facts.com> - 2025-08-11 19:16 +0000
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-08-11 17:03 -0700
Re: It is stunning when you see how badly Windows operates: indexing "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2025-08-12 12:36 +0800
Re: It is stunning when you see how badly Windows operates: indexing WolfFan <akwolffan@zoho.com> - 2025-08-10 18:33 -0400
Re: It is stunning when you see how badly Windows operates: indexing Paul <nospam@needed.invalid> - 2025-08-11 02:12 -0400
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-08-11 11:25 -0700
Re: It is stunning when you see how badly Windows operates: indexing Paul <nospam@needed.invalid> - 2025-08-11 18:02 -0400
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-08-11 17:01 -0700
Re: It is stunning when you see how badly Windows operates: indexing Paul <nospam@needed.invalid> - 2025-08-12 01:24 -0400
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-08-12 08:49 -0700
Re: It is stunning when you see how badly Windows operates: indexing Marion <marion@facts.com> - 2025-08-12 17:10 +0000
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-08-12 08:55 -0700
Re: It is stunning when you see how badly Windows operates: indexing Tom Elam <thomas.e.elam@gmail.com> - 2025-08-17 16:03 -0400
Re: It is stunning when you see how badly Windows operates: indexing Paul <nospam@needed.invalid> - 2025-08-17 18:15 -0400
csiph-web