Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.mac.advocacy > #136395 > unrolled thread

It is stunning when you see how badly Windows operates: indexing

Back to article view | Back to comp.sys.mac.advocacy

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

#136446

On 2025-08-10 21:04, Paul wrote:
> On Sun, 8/10/2025 8:00 PM, Alan wrote:
> 
>>>
>>> You don't have to "cp" or "copy" a file to copy it as such.
>>
>> OK. So what? I wasn't copying files when Windows wanted to re-index them...
>>
>> ...I was just moving them.
> 
> And to help you, I have explained the implementation.

You're just explaining WHY it does it badly, but the truth is that it 
doesn't HAVE to be done badly.

> 
> The USN Journal is not a brain trust. All it can do, is
> report *every* file system change, so that utilities
> like Everything.exe or the Search Indexer in Windows,
> are apprised of file system changes.
> 
> If you move a file, there is a "deletefile" in the
> USN Journal and a "createfile". Suggestions ? Timmy ?
> It is NOT ALLOWED to use calculus. That's how all file
> system operations work. Each operation is independent,
> primitive, and simple. This is how developers stay out
> of trouble, by using the KISS principle. They are
> NOT ALLOWED to notice "hey, this is the same file
> as before, let's just wodge this here metadata
> around in the inverted index". Multiple entries
> inside the inverted index would need to be corrected
> if you tried to do this sort of calculus. Instead,
> the primitives the software support is "remove index
> entry" or "add index entry", which requires a Merge
> of a small index, into the Master index.

No, actually.

When you MOVE a file, the USN Journal records this as a "rename".

A file that is moved on an NTFS volume keeps the same File Reference 
Number, so there is no reason AT ALL that the indexer shouldn't be able 
to see that all that has changed about the file is the path TO that file.

So you lose right from the outset with your attempt to justify the 
horrible performance of Windows indexing.

> 
> People propose non-primitive operations all the time.
> I like to joke about it too. For example, if I want
> to delete 2000 files, why couldn't the OS just freeze,
> open the $MFT, pretend it was a copy of Notepad,
> delete 2000 lines in the file, then Save. That would
> work wouldn't it ? As much as we would like that to
> happen, that is not allowed.

Not germane to our topic.

> 
> The closest Microsoft has come to violating the non-primitive
> rule, is the creation of MBR2GPT.exe utility. And we are
> not quite sure whether that was a Microsoft employee who
> wrote that, or it is someone outside the organization. What is
> interesting about that utility, is I did two test cases
> where I thought the offered materials were the same, and
> the output of the utility was entirely different (different
> set of partitions and in a different order). The utility is
> its own best example of why we do not short-circuit the
> primitives in things. (This is a utility that makes multiple
> partition changes, via one press of the button. A backup is
> advised, by the audience out here.)
> 
> Even in its current state, the Federated Search is not a
> finished project. It is not finished, because it has
> a tick box for "filename only" indexing, and that tick
> box does not work. I got the distinct impression that
> for a couple of years, someone must have left Microsoft,
> and there seemed to be nobody available to work on Federated
> Search. But as evidence that changed, the database used
> for the Index was changed from Jet Blue to Sqlite. which
> makes no difference to how the thing behaves for the end
> user. But it does suggest that someone opened up the
> source for that package and messed with it.
> 
>     [Picture]
> 
>      https://i.postimg.cc/sgVGZjwy/Indexing-Options.gif
> 
>     Paul
> 

[toc] | [prev] | [next] | [standalone]

#136480

On 2025-08-11 10:57, Alan wrote:
> On 2025-08-10 21:04, Paul wrote:
>> On Sun, 8/10/2025 8:00 PM, Alan wrote:
>>
>>>>
>>>> You don't have to "cp" or "copy" a file to copy it as such.
>>>
>>> OK. So what? I wasn't copying files when Windows wanted to re-index 
>>> them...
>>>
>>> ...I was just moving them.
>>
>> And to help you, I have explained the implementation.
> 
> You're just explaining WHY it does it badly, but the truth is that it 
> doesn't HAVE to be done badly.
> 
>>
>> The USN Journal is not a brain trust. All it can do, is
>> report *every* file system change, so that utilities
>> like Everything.exe or the Search Indexer in Windows,
>> are apprised of file system changes.
>>
>> If you move a file, there is a "deletefile" in the
>> USN Journal and a "createfile". Suggestions ? Timmy ?
>> It is NOT ALLOWED to use calculus. That's how all file
>> system operations work. Each operation is independent,
>> primitive, and simple. This is how developers stay out
>> of trouble, by using the KISS principle. They are
>> NOT ALLOWED to notice "hey, this is the same file
>> as before, let's just wodge this here metadata
>> around in the inverted index". Multiple entries
>> inside the inverted index would need to be corrected
>> if you tried to do this sort of calculus. Instead,
>> the primitives the software support is "remove index
>> entry" or "add index entry", which requires a Merge
>> of a small index, into the Master index.
> 
> No, actually.
> 
> When you MOVE a file, the USN Journal records this as a "rename".
 > > A file that is moved on an NTFS volume keeps the same File Reference
> Number, so there is no reason AT ALL that the indexer shouldn't be able 
> to see that all that has changed about the file is the path TO that file.
> 
> So you lose right from the outset with your attempt to justify the 
> horrible performance of Windows indexing.
No surprise that you've address every post in this thread except this 
one, is it?

[toc] | [prev] | [next] | [standalone]

#136435

On 10/8/2025 11:25 pm, Paul wrote:
> 
> It *does* work without an index, or at least, with a minimally-sized index.
> It is horribly slow if done that way (it fills in the areas missing from
> the index file, via brute force search). Any time the File Explorer does something,
> it may feel the need to look for an icon to represent the file, and the
> graphical overhead slows everything down.

Indexes can be corrupted, and it takes time to rebuild it.

Anyway, searching Office documents and PDFs is different from searching 
plain-text files.


-- 
   @~@   Simplicity is Beauty! Remain silent! Drink, Blink, Stretch!
  / v \  May the Force and farces be with you! Live long and prosper!!
/( _ )\ https://sites.google.com/site/changmw/
   ^ ^   https://github.com/changmw/changmw

[toc] | [prev] | [next] | [standalone]

#136453

On Mon, 11 Aug 2025 20:22:12 +0800, Mr. Man-wai Chang wrote :


> On 10/8/2025 11:25 pm, Paul wrote:
>> 
>> It *does* work without an index, or at least, with a minimally-sized index.
>> It is horribly slow if done that way (it fills in the areas missing from
>> the index file, via brute force search). Any time the File Explorer does something,
>> it may feel the need to look for an icon to represent the file, and the
>> graphical overhead slows everything down.
> 
> Indexes can be corrupted, and it takes time to rebuild it.
> 
> Anyway, searching Office documents and PDFs is different from searching 
> plain-text files.

1. This thread is from a known Apple troll herd animal who extols the 
   virtues of everything that Apple marketing has fed him to believe.

2. His claim is that he saw issues in how Windows 10 handles file indexing,
   especially in relation to re-indexing files in OneDrive and SharePoint. 

3. Nobody disagrees macOS Spotlight is generally considered superior 
   to Windows Search when it comes to indexing efficiency & speed 
   (as Spotlight uses metadata & file attributes to track files).

4. What Apple marketing never told these Apple troll herd animals is that
   Spotlight is known to be very often exploited (e.g., "Sploitlight").

5. The fact is that malicious Spotlight plugins scan & log private 
   content without triggering user consent dialogs, which makes it
   almost impossible for users to detect unauthorized access.

6. Worse, because macOS Spotlight also indexes data synced via iCloud,
   compromising one Mac exposes data from linked iPhones or iPads too.

7. For truly sensitive data, encryption is recommended, as Spotlight
   can easily expose metadata even if files are hidden from search.

[toc] | [prev] | [next] | [standalone]

#136464

On 2025-08-11 12:16, Marion wrote:
> On Mon, 11 Aug 2025 20:22:12 +0800, Mr. Man-wai Chang wrote :
> 
> 
>> On 10/8/2025 11:25 pm, Paul wrote:
>>>
>>> It *does* work without an index, or at least, with a minimally-sized index.
>>> It is horribly slow if done that way (it fills in the areas missing from
>>> the index file, via brute force search). Any time the File Explorer does something,
>>> it may feel the need to look for an icon to represent the file, and the
>>> graphical overhead slows everything down.
>>
>> Indexes can be corrupted, and it takes time to rebuild it.
>>
>> Anyway, searching Office documents and PDFs is different from searching
>> plain-text files.
> 
> 1. This thread is from a known Apple troll herd animal who extols the
>     virtues of everything that Apple marketing has fed him to believe.
> 
> 2. His claim is that he saw issues in how Windows 10 handles file indexing,
>     especially in relation to re-indexing files in OneDrive and SharePoint.

Utterly incorrect.

I was observing how it re-indexed files that were completely LOCAL when 
the re-indexing occurred.

> 
> 3. Nobody disagrees macOS Spotlight is generally considered superior
>     to Windows Search when it comes to indexing efficiency & speed
>     (as Spotlight uses metadata & file attributes to track files).
> 
> 4. What Apple marketing never told these Apple troll herd animals is that
>     Spotlight is known to be very often exploited (e.g., "Sploitlight").

Where "very often" apprently means "once".

> 
> 5. The fact is that malicious Spotlight plugins scan & log private
>     content without triggering user consent dialogs, which makes it
>     almost impossible for users to detect unauthorized access.

And the fact is that you have to INSTALL those plugins for it to happen 
at all.

> 
> 6. Worse, because macOS Spotlight also indexes data synced via iCloud,
>     compromising one Mac exposes data from linked iPhones or iPads too.
> 
> 7. For truly sensitive data, encryption is recommended, as Spotlight
>     can easily expose metadata even if files are hidden from search.

[toc] | [prev] | [next] | [standalone]

#136469

On 12/8/2025 3:16 am, Marion wrote:
> 
> 5. The fact is that malicious Spotlight plugins scan & log private
>     content without triggering user consent dialogs, which makes it
>     almost impossible for users to detect unauthorized access.
> 
> 6. Worse, because macOS Spotlight also indexes data synced via iCloud,
>     compromising one Mac exposes data from linked iPhones or iPads too.

That's adsurb ridiculous! Thanks!

-- 
   @~@   Simplicity is Beauty! Remain silent! Drink, Blink, Stretch!
  / v \  May the Force and farces be with you! Live long and prosper!!
/( _ )\ https://sites.google.com/site/changmw/
   ^ ^   https://github.com/changmw/changmw

[toc] | [prev] | [next] | [standalone]

#136422

On Aug 9, 2025, Alan wrote
(in article <1078llp$1he7o$3@dont-email.me>):

> I'm going some tech support for my brother today, and that's meant
> looking "under the hood" of his Windows 10 machine.
>
> And it is astounding how poorly Windows handles indexing content.
>
> I had to uninstall OneDrive and set it up again from scratch and in the
> course of that I moved the contents that had previously been
> synchronized to two folders with "(Old)" added to make sure that nothing
> got lost when we did it.
>
> And I wasn't surprised when resetting his connections to his OneDrive
> store and the company Sharepoint store set off a flurry of indexing. I
> wasn't even surprised that that took a bit of time to finish; I was
> re-downloading a lot of files which from the perspective of Windows, all
> needed to be indexed anew.
>
> What was completely surprising was that simply moving the those two
> "Old" folders immediately caused Windows to re-index that content! I
> decided to clean up the two separate "Old" stores into a single folder,
> and all of a sudden, the indexing which was at 0 in
> Settings:Search:Searching Windows
>
> Windows isn't smart enough to recognize that these are all files that
> its already indexed and they're now just in a new location!
>
> About 80,000 files were move about 30 minutes ago, and the re-indexing
> isn't even 25% done!
>
> If I do a similar thing on macOS, it's done almost before the files have
> finished the move.

Wanna have some fun?

1. set up a folder in Win10/11 in an OneDrive folder.

1.a verify that a Mac can access that OneDrive

2. move the folder to inside a different folder in the OneDrive folder.

3. go to the Mac, access the OneDrive. Try to find one of the files in the 
folder you just moved. Bet that you find it.

3.a go to the WinBox try to find the same file. Bet that you won’t.

4. repeat the above steps, using DropBox instead of OneDrive.

5. Repeat, using GoogleDrive.

6. Repeat, using iCloud.

no further comment.

[toc] | [prev] | [next] | [standalone]

#136431

On Sun, 8/10/2025 6:33 PM, WolfFan wrote:

> Wanna have some fun?
> 
> 1. set up a folder in Win10/11 in an OneDrive folder.
> 
> 1.a verify that a Mac can access that OneDrive
> 
> 2. move the folder to inside a different folder in the OneDrive folder.
> 
> 3. go to the Mac, access the OneDrive. Try to find one of the files in the 
> folder you just moved. Bet that you find it.
> 
> 3.a go to the WinBox try to find the same file. Bet that you won’t.
> 
> 4. repeat the above steps, using DropBox instead of OneDrive.
> 
> 5. Repeat, using GoogleDrive.
> 
> 6. Repeat, using iCloud.
> 
> no further comment.
> 

The closest I was able to get, to a utility to list the current contents
of OneDrive, is this one.

https://learn.microsoft.com/en-us/answers/questions/5145149/how-do-i-create-generate-a-list-of-folders-or-file?forum=msoffice-all&referrer=answers

    1) Install PowerShell 7.2 or later (PnP PowerShell is only supported in PowerShell 7)

    2) Install-Module -Name PnP.PowerShell -RequiredVersion 2.2.0

       ( https://www.powershellgallery.com/packages/pnp.powershell/2.2.0 )

I tried to find a cleaner copy of that, but no luck.

The PNP package also has a GetFile, so once a script returns a URL list,
you can fetch any individual file with PNP as well (one at a time).

*******

This is the more direct approach. Untested (I don't use OneDrive).

https://learn.microsoft.com/en-us/answers/questions/5293014/force-sync-in-onedrive

    You can also force a manual sync by following these steps:

    Press the Windows key + R to open the Run dialog box.
    Type "cmd" and press Enter to open the Command Prompt.
    Type "cd %userprofile%\OneDrive" and press Enter to navigate to the OneDrive folder.
    Type "onedrive.exe /sync" and press Enter to force a manual sync.

And in theory at least, that might pick up the folder change.
Then have a look, search, or whatever.

   Paul

[toc] | [prev] | [next] | [standalone]

#136449

On 2025-08-10 23:12, Paul wrote:
> On Sun, 8/10/2025 6:33 PM, WolfFan wrote:
> 
>> Wanna have some fun?
>>
>> 1. set up a folder in Win10/11 in an OneDrive folder.
>>
>> 1.a verify that a Mac can access that OneDrive
>>
>> 2. move the folder to inside a different folder in the OneDrive folder.
>>
>> 3. go to the Mac, access the OneDrive. Try to find one of the files in the
>> folder you just moved. Bet that you find it.
>>
>> 3.a go to the WinBox try to find the same file. Bet that you won’t.
>>
>> 4. repeat the above steps, using DropBox instead of OneDrive.
>>
>> 5. Repeat, using GoogleDrive.
>>
>> 6. Repeat, using iCloud.
>>
>> no further comment.
>>
> 
> The closest I was able to get, to a utility to list the current contents
> of OneDrive, is this one.
> 
> https://learn.microsoft.com/en-us/answers/questions/5145149/how-do-i-create-generate-a-list-of-folders-or-file?forum=msoffice-all&referrer=answers
> 
>      1) Install PowerShell 7.2 or later (PnP PowerShell is only supported in PowerShell 7)
> 
>      2) Install-Module -Name PnP.PowerShell -RequiredVersion 2.2.0
> 
>         ( https://www.powershellgallery.com/packages/pnp.powershell/2.2.0 )
> 
> I tried to find a cleaner copy of that, but no luck.
> 
> The PNP package also has a GetFile, so once a script returns a URL list,
> you can fetch any individual file with PNP as well (one at a time).
> 
> *******
> 
> This is the more direct approach. Untested (I don't use OneDrive).
> 
> https://learn.microsoft.com/en-us/answers/questions/5293014/force-sync-in-onedrive
> 
>      You can also force a manual sync by following these steps:
> 
>      Press the Windows key + R to open the Run dialog box.
>      Type "cmd" and press Enter to open the Command Prompt.
>      Type "cd %userprofile%\OneDrive" and press Enter to navigate to the OneDrive folder.
>      Type "onedrive.exe /sync" and press Enter to force a manual sync.
> 
> And in theory at least, that might pick up the folder change.
> Then have a look, search, or whatever.
> 
>     Paul
On a Mac, just point a search at the top-level OneDrive folder and 
search for file name with '""' (or I can search for any other criterion 
I know will return everything; "modified:<2025-08-12" for instance).

All the items appear in a flat list practically as fast as I can type it.


:-)

[toc] | [prev] | [next] | [standalone]

#136458

On Mon, 8/11/2025 2:25 PM, Alan wrote:
> On 2025-08-10 23:12, Paul wrote:
>>
>> This is the more direct approach. Untested (I don't use OneDrive).
>>
>> https://learn.microsoft.com/en-us/answers/questions/5293014/force-sync-in-onedrive
>>
>>      You can also force a manual sync by following these steps:
>>
>>      Press the Windows key + R to open the Run dialog box.
>>      Type "cmd" and press Enter to open the Command Prompt.
>>      Type "cd %userprofile%\OneDrive" and press Enter to navigate to the OneDrive folder.
>>      Type "onedrive.exe /sync" and press Enter to force a manual sync.
>>
>> And in theory at least, that might pick up the folder change.
>> Then have a look, search, or whatever.
>>
>>     Paul
> On a Mac, just point a search at the top-level OneDrive folder and search for file name with '""' (or I can search for any other criterion I know will return everything; "modified:<2025-08-12" for instance).
> 
> All the items appear in a flat list practically as fast as I can type it.
> 
> 
> :-)

I'm surprised the OneDrive process, is not in constant communication with
the Mother Ship, and able to get config changes from the Cloud.

You could log in from the web and see your goods, but that's not
as convenient.

   Paul

[toc] | [prev] | [next] | [standalone]

#136463

On 2025-08-11 15:02, Paul wrote:
> On Mon, 8/11/2025 2:25 PM, Alan wrote:
>> On 2025-08-10 23:12, Paul wrote:
>>>
>>> This is the more direct approach. Untested (I don't use OneDrive).
>>>
>>> https://learn.microsoft.com/en-us/answers/questions/5293014/force-sync-in-onedrive
>>>
>>>       You can also force a manual sync by following these steps:
>>>
>>>       Press the Windows key + R to open the Run dialog box.
>>>       Type "cmd" and press Enter to open the Command Prompt.
>>>       Type "cd %userprofile%\OneDrive" and press Enter to navigate to the OneDrive folder.
>>>       Type "onedrive.exe /sync" and press Enter to force a manual sync.
>>>
>>> And in theory at least, that might pick up the folder change.
>>> Then have a look, search, or whatever.
>>>
>>>      Paul
>> On a Mac, just point a search at the top-level OneDrive folder and search for file name with '""' (or I can search for any other criterion I know will return everything; "modified:<2025-08-12" for instance).
>>
>> All the items appear in a flat list practically as fast as I can type it.
>>
>>
>> :-)
> 
> I'm surprised the OneDrive process, is not in constant communication with
> the Mother Ship, and able to get config changes from the Cloud.
> 
> You could log in from the web and see your goods, but that's not
> as convenient.
You have now shown you lack anything resembling a clue about the topic 
of this thread.

[toc] | [prev] | [next] | [standalone]

#136471

On Mon, 8/11/2025 8:01 PM, Alan wrote:

> You have now shown you lack anything resembling a clue about the topic of this thread.

Windows starts with mistakes made decades ago, and
everything traces from that.

They already tried to redesign the file system. It was called
ReFS. ReFS was withdrawn, and I haven't seen a summary of
what they didn't like about their design. Presumably it
had a lot of baggage to carry, to reproduce the features of NTFS.

It does occasionally pop up as a topic. It's not completely dead.
I think you might, by some means, be able to create one of those.
But I don't know why you would bother.

The Search Indexer is an *inverted* index. It's a lot easier
to deal with an index which is right way up, and things are
filed by filename. If you look at the actual database. two
tables are wired together as parent-number things. Whereas
the table with the index materials is a "giant blob". I could not
make sense of it, in a quick glance, but that wasn't why I was there.
I was interested in whether you could make a file list from
what is in the 4GB index, and you can make a file list of
things that were scanned.

   Paul

[toc] | [prev] | [next] | [standalone]

#136479

On 2025-08-11 22:24, Paul wrote:
> On Mon, 8/11/2025 8:01 PM, Alan wrote:
> 
>> You have now shown you lack anything resembling a clue about the topic of this thread.
> 
> Windows starts with mistakes made decades ago, and
> everything traces from that.

OK... ...how is that an excuse?

> 
> They already tried to redesign the file system. It was called
> ReFS. ReFS was withdrawn, and I haven't seen a summary of
> what they didn't like about their design. Presumably it
> had a lot of baggage to carry, to reproduce the features of NTFS.
> 
> It does occasionally pop up as a topic. It's not completely dead.
> I think you might, by some means, be able to create one of those.
> But I don't know why you would bother.
> 
> The Search Indexer is an *inverted* index. It's a lot easier
> to deal with an index which is right way up, and things are
> filed by filename. If you look at the actual database. two
> tables are wired together as parent-number things. Whereas
> the table with the index materials is a "giant blob". I could not
> make sense of it, in a quick glance, but that wasn't why I was there.
> I was interested in whether you could make a file list from
> what is in the 4GB index, and you can make a file list of
> things that were scanned.
An inverted index is an absolute NECESSITY when searching for anything 
aside from the file name.

Things being "filed by filename" is pretty much a tautology.

You should stop pontificating about subjects about which you clearly 
know very little.

[toc] | [prev] | [next] | [standalone]

#136483

On Tue, 12 Aug 2025 01:24:40 -0400, Paul wrote :


> Windows starts with mistakes made decades ago, and
> everything traces from that.

Paul,

You are helpful. You've always been helpful. For years.
Maybe even for decades on this newsgroup (and others).

You're even kind to others. But you're dealing with Alan Baker.
He has no kind or purposefully helpful bone in his entire body.

His only goal is inane MAGA religious zealotry at all costs.
Hence, this discussion, to him, has nothing to do with Windows.

It's all about Making Apple Great Again.

You and I and most Windows posters can easily accept that Bill Gates was
not a God, and worse, many (most? all?) of his decisions were lousy.

But the MAGA Apple trolls are different. 
The feel their God, Steve Jobs and now Tim Cook, are infallible.

There are no flaws in Apple software. 
None. 

They can't have flaws.
Because Gods don't have flaws. 

I hope, for your sanity, you keep that in mind when dealing with them.

In addition, Alan Baker lives on Usenet for his own daily amusement.
He has no goal other than to promote Apple & to enjoy the process herein.

He's a sadistically unprepossessing person devoid of basic humanity.
You're welcome to deal with him - but at the expense of basic reality.

[toc] | [prev] | [next] | [standalone]

#136482

On 2025-08-11 15:02, Paul wrote:
> On Mon, 8/11/2025 2:25 PM, Alan wrote:
>> On 2025-08-10 23:12, Paul wrote:
>>>
>>> This is the more direct approach. Untested (I don't use OneDrive).
>>>
>>> https://learn.microsoft.com/en-us/answers/questions/5293014/force-sync-in-onedrive
>>>
>>>       You can also force a manual sync by following these steps:
>>>
>>>       Press the Windows key + R to open the Run dialog box.
>>>       Type "cmd" and press Enter to open the Command Prompt.
>>>       Type "cd %userprofile%\OneDrive" and press Enter to navigate to the OneDrive folder.
>>>       Type "onedrive.exe /sync" and press Enter to force a manual sync.
>>>
>>> And in theory at least, that might pick up the folder change.
>>> Then have a look, search, or whatever.
>>>
>>>      Paul
>> On a Mac, just point a search at the top-level OneDrive folder and search for file name with '""' (or I can search for any other criterion I know will return everything; "modified:<2025-08-12" for instance).
>>
>> All the items appear in a flat list practically as fast as I can type it.
>>
>>
>> :-)
> 
> I'm surprised the OneDrive process, is not in constant communication with
> the Mother Ship, and able to get config changes from the Cloud.
> 
> You could log in from the web and see your goods, but that's not
> as convenient.
You don't actually bother reading what you're replying to...

...do you?

Nor do you appear to know what a comma, [sic] used for in a sentence.

[toc] | [prev] | [next] | [standalone]

#136613

On 8/9/2025 7:30 PM, Alan wrote:
> I'm going some tech support for my brother today, and that's meant 
> looking "under the hood" of his Windows 10 machine.
> 
> And it is astounding how poorly Windows handles indexing content.
> 
> I had to uninstall OneDrive and set it up again from scratch and in the 
> course of that I moved the contents that had previously been 
> synchronized to two folders with "(Old)" added to make sure that nothing 
> got lost when we did it.
> 
> And I wasn't surprised when resetting his connections to his OneDrive 
> store and the company Sharepoint store set off a flurry of indexing. I 
> wasn't even surprised that that took a bit of time to finish; I was re- 
> downloading a lot of files which from the perspective of Windows, all 
> needed to be indexed anew.
> 
> What was completely surprising was that simply moving the those two 
> "Old" folders immediately caused Windows to re-index that content! I 
> decided to clean up the two separate "Old" stores into a single folder, 
> and all of a sudden, the indexing which was at 0 in 
> Settings:Search:Searching Windows
> 
> Windows isn't smart enough to recognize that these are all files that 
> its already indexed and they're now just in a new location!
> 
> About 80,000 files were move about 30 minutes ago, and the re-indexing 
> isn't even 25% done!
> 
> If I do a similar thing on macOS, it's done almost before the files have 
> finished the move.

I'm really glad Alan does not know how badly the move to Modern Sleep 
has screwed up what was a perfectly good Windows feature. This goes back 
to at least 2020.

https://mspoweruser.com/microsofts-modern-standby-is-draining-certain-laptops/

In addition, some Windows machine are only able to perform Modern Sleep. 
Mine was one until I found a registry hack to enable Hibernation.

[toc] | [prev] | [next] | [standalone]

#136618

On Sun, 8/17/2025 4:03 PM, Tom Elam wrote:
> On 8/9/2025 7:30 PM, Alan wrote:
>> I'm going some tech support for my brother today, and that's meant looking "under the hood" of his Windows 10 machine.
>>
>> And it is astounding how poorly Windows handles indexing content.
>>
>> I had to uninstall OneDrive and set it up again from scratch and in the course of that I moved the contents that had previously been synchronized to two folders with "(Old)" added to make sure that nothing got lost when we did it.
>>
>> And I wasn't surprised when resetting his connections to his OneDrive store and the company Sharepoint store set off a flurry of indexing. I wasn't even surprised that that took a bit of time to finish; I was re- downloading a lot of files which from the perspective of Windows, all needed to be indexed anew.
>>
>> What was completely surprising was that simply moving the those two "Old" folders immediately caused Windows to re-index that content! I decided to clean up the two separate "Old" stores into a single folder, and all of a sudden, the indexing which was at 0 in Settings:Search:Searching Windows
>>
>> Windows isn't smart enough to recognize that these are all files that its already indexed and they're now just in a new location!
>>
>> About 80,000 files were move about 30 minutes ago, and the re-indexing isn't even 25% done!
>>
>> If I do a similar thing on macOS, it's done almost before the files have finished the move.
> 
> I'm really glad Alan does not know how badly the move to Modern Sleep has screwed up what was a perfectly good Windows feature. This goes back to at least 2020.
> 
> https://mspoweruser.com/microsofts-modern-standby-is-draining-certain-laptops/
> 
> In addition, some Windows machine are only able to perform Modern Sleep. Mine was one until I found a registry hack to enable Hibernation.
> 

But that's really no different than regular ACPI failures.

The "powercfg" utility, has some tools for collecting reports and
finding "hints" of a root cause.

In your example, since the machine is not entering a low power state,
I would be checking LastWake to see it bouncing out of the low power state.

The machine I'm typing on, draws 33W while idling in S0. Your example
is 27.5W in fake Modern Standby, which means it is fully in S0.
My machine includes a plugin video card (the inclusion of which
was forced by a bug in the design). The lowest S0 Idle I've got,
is a 6 core machine that runs idling at 22 watts (using its iGPU).

Then you have all possible combinations of broken and working stuff.

https://www.elevenforum.com/t/disable-modern-standby-in-windows-10-and-windows-11.3929/

The theme repeats over and over again with modern computers.
Additional complexity, enlarged table of possibilities, and little
to show for all of it.

There is the potential (but not the guarantee) of a BIOS switch,
to aid in changing ACPI model.

And the worst case for laptops, is where the ACPI table has syntax
errors, the Linux parser points out the problem, the manufacturer
refuses (or is unable) to edit the BIOS and correct that part of it.
It's not always possible, when purchasing, to catch problems
like that before they sting you.

   Paul

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.sys.mac.advocacy

csiph-web