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.
Alan wrote on 8/9/2025 6:30 PM:Believe me, I have.
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.
So why don't you tell him about mac OS? Then you wouldn't have to do
all that work taking care of his shitty windows computer.
On 2025-08-09 16:55, Hank Rogers wrote:
Alan wrote on 8/9/2025 6:30 PM:Believe me, I have.
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.
So why don't you tell him about mac OS? Then you wouldn't have to do
all that work taking care of his shitty windows computer.
There was a time when he couldn't use a Mac because there was certain software for his industry that wasn't available.
But now he's using that software via a Windows Remote Access connection
to a server operated by the developer, his next machine just might be a Mac.
:-)
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.
Alan <nuh-uh@nope.com> wrote:
On 2025-08-09 16:55, Hank Rogers wrote:
Alan wrote on 8/9/2025 6:30 PM:Believe me, I have.
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.
So why don't you tell him about mac OS? Then you wouldn't have to do
all that work taking care of his shitty windows computer.
There was a time when he couldn't use a Mac because there was certain
software for his industry that wasn't available.
But now he's using that software via a Windows Remote Access connection
to a server operated by the developer, his next machine just might be a Mac. >>
:-)
You should buy him a new Mac for his next birthday! Because he’s still really using windows; just some other person’s windows machine. That’s pretty pathetic.
Don’t give up. He may come to his senses and embrace apple’s wonderful ecosystem.
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.
All computers have problems. As a former Apple computer user,
who used to belong to a web fora where I helped out, we tried
to be honest about our experiences, for the benefit of one another.
There was none of this smug wand waving you see today.
On 10/8/2025 7:30 am, 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.
This Indexing Service should have been *OPTIONAL*. The search function should work regardless of the indexing settings.
Why can't I choose a slow but more reliable method that doesn't need indexes?? :)
On Sun, 8/10/2025 12:34 AM, Mr. Man-wai Chang wrote:I'm sorry, but it does matter how cleverly and well the OS is coded to
On 10/8/2025 7:30 am, 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.
This Indexing Service should have been *OPTIONAL*. The search function should work regardless of the indexing settings.
Why can't I choose a slow but more reliable method that doesn't need indexes?? :)
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.
"Everything.exe" from voidtools, is about the best you can do for a filename-only solution. The file it keeps, just has filenames in it.
And for NTFS partitions, it keeps the list of files up to date, using
the USN Journal information.
It does not matter what OS, any time the storage has
a lot of files, the behavior does not scale well. it can take
an hour, just to count the files in a folder like this one.
"Everything.exe" is also going to need an hour for this one,
as the program does a stat() on each file. Early versions of
the Voidtools program, did not include file size in the file list,
and the software was a lot faster then.
[Picture]
https://i.postimg.cc/Y2NWHSNk/test-volume-large-file-set.gif
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.
On 2025-08-10 08:25, Paul wrote:
On Sun, 8/10/2025 12:34 AM, Mr. Man-wai Chang wrote:I'm sorry, but it does matter how cleverly and well the OS is coded to do the indexing.
On 10/8/2025 7:30 am, 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.
This Indexing Service should have been *OPTIONAL*. The search function should work regardless of the indexing settings.
Why can't I choose a slow but more reliable method that doesn't need indexes?? :)
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.
"Everything.exe" from voidtools, is about the best you can do for a
filename-only solution. The file it keeps, just has filenames in it.
And for NTFS partitions, it keeps the list of files up to date, using
the USN Journal information.
It does not matter what OS, any time the storage has
a lot of files, the behavior does not scale well. it can take
an hour, just to count the files in a folder like this one.
"Everything.exe" is also going to need an hour for this one,
as the program does a stat() on each file. Early versions of
the Voidtools program, did not include file size in the file list,
and the software was a lot faster then.
[Picture]
https://i.postimg.cc/Y2NWHSNk/test-volume-large-file-set.gif
The fact of the matter is that Windows's indexing is orders of magnitude slower than macOS's indexing.
If I move 80,000 files on macOS, the OS is smart enough to know that it doesn't need to update every piece of information about those files; only that they are now in a new location.
The very fact that a tool like "Everything.exe" has been developed for Windows shows just how poorly done the built-in indexing is.
On Sun, 8/10/2025 3:37 PM, Alan wrote:
On 2025-08-10 08:25, Paul wrote:
On Sun, 8/10/2025 12:34 AM, Mr. Man-wai Chang wrote:I'm sorry, but it does matter how cleverly and well the OS is coded to do the indexing.
On 10/8/2025 7:30 am, 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.
This Indexing Service should have been *OPTIONAL*. The search function should work regardless of the indexing settings.
Why can't I choose a slow but more reliable method that doesn't need indexes?? :)
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.
"Everything.exe" from voidtools, is about the best you can do for a
filename-only solution. The file it keeps, just has filenames in it.
And for NTFS partitions, it keeps the list of files up to date, using
the USN Journal information.
It does not matter what OS, any time the storage has
a lot of files, the behavior does not scale well. it can take
an hour, just to count the files in a folder like this one.
"Everything.exe" is also going to need an hour for this one,
as the program does a stat() on each file. Early versions of
the Voidtools program, did not include file size in the file list,
and the software was a lot faster then.
[Picture]
https://i.postimg.cc/Y2NWHSNk/test-volume-large-file-set.gif
The fact of the matter is that Windows's indexing is orders of magnitude slower than macOS's indexing.
If I move 80,000 files on macOS, the OS is smart enough to know that it doesn't need to update every piece of information about those files; only that they are now in a new location.
The very fact that a tool like "Everything.exe" has been developed for
Windows shows just how poorly done the built-in indexing is.
https://en.wikipedia.org/wiki/Apple_File_System
"Despite the ubiquity of APFS volumes in today's Macs and the format's
2016 introduction, third-party repair utilities continue to have notable
limitations in supporting APFS volumes, due to Apple's delayed release of
complete documentation.
According to Alsoft, the maker of DiskWarrior, Apple's 2018 release of
partial APFS format documentation has delayed the creation of a version of
DiskWarrior that can safely rebuild APFS disks.[44] Competing products,
including MicroMat's TechTool and Prosoft's Drive Genius, are expected
to increase APFS support as well."
Not with a barge pole. See ? I've been to your rodeo, and rode that pony. Back when I was an Apple user, you did not own a Mac without a copy of DiskWarrior.
Physical media with a serial number on the label, was sent to you.
[Picture]
https://i.postimg.cc/k5fPj6hg/discwarrior.jpg
*******
You don't have to "cp" or "copy" a file to copy it as such.
Windows has hardlinks, which allow the data clusters to stay put,
and adding an additional $FILENAME to the $MFT 1KB entry is sufficient
to make a file appear in two places at once. By deleting the first
$FILENAME, the second $FILENAME still owns the clusters.
File 479487
\Windows\System32\shell32.dll
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 65604464-65622255 (0x3e90b70-0x3e950ef)
$EA_INFORMATION (resident)
$EA (resident)
Attribute Type 0x100 $DSC (resident)
Attribute Type 0x100 $TXF_DATA (resident)
The -i option in Linux, includes the inode number as the first numeric field. And the inode number on Linux, is made equal to the Filenum. This is how
we know we are seeing the two $FILE_NAME values. The nfi.exe utility, sorely needs this information added to it, as otherwise the listing via nfi.exe misses stuff.
These two files share the same clusters. ls -algtRi
./Windows/System32:
total 2371265
479487 -rwxrwxrwx 2 mint 9108432 Jul 9 02:02 shell32.dll
./Windows/WinSxS/amd64_microsoft-windows-shell32_31bf3856ad364e35_10.0.22621.5547_none_4c0780878d97ec32:
total 40256
573225 drwxrwxrwx 1 mint 13107200 Jul 11 11:05 ..
454973 drwxrwxrwx 1 mint 4096 Jul 9 02:02 .
479487 -rwxrwxrwx 2 mint 9108432 Jul 9 02:02 shell32.dll
*******
In other words, to copy the file during a Patch Tuesday run, the OS first unpacked a new version of package in WinSxS. That would be the first $FILE_NAME
created.
Then, it created a hardlink in C:\Windows\System32 for shell32.dll , and now one set of clusters, has two file names. You could delete the WinSxS folder and the copy in System32 would still exist, and so would the clusters
65604464-65622255 (22255-4464+1)/8 = 2224 clusters
that belong to the file.
*******
Windows has various versions of features that correspond roughly
to things seen on other OSes. The features are not exactly the same,
but similar.
I could copy a large file, without repeating the clusters, just by using
a hard link. As long as that hard link stayed on the same physical partition.
People here, do not copy things that way, they would use a Move done
with the mouse, or use some utility that is smart enough to do it
the efficient way. The danger with a Move on any platform, is
a power fail at some microsecond while the operation is being done.
There is usually a crevasse your file can fall into, if you use "Move". Having a UPS or a battery on the equipment, makes that marginally safer.
A "Move" on FAT32, might be unsafe, while a "Move" on NTFS could be made safer.
Copying the dumb way, is what happens when you're in a rush. And when
dealing with things like VM containers, you're not usually in that
kind of a rush. Like, if I was moving a 2TB MRIMG backup file around,
I would pause and think about what I was doing. Doing copy-pasta would be furthest from mind, because of how long it could take if I did it the
dumbest way possible.
*******Again: why the HELL do I care about deleting files.
While the nfi.exe utility displays items this way...
File 479487
\Windows\System32\shell32.dll
they are not stored that way. The string "shell32.dll" is in the
1KB entry. And an integer number like "12345" references the parent
directory which is "System32". To print out the absolute path,
involves walking the tree from parent to parent, until you've
assembled all the parent names. When you reach filenum 5 at the top
of the tree, its parent is filenum 5 (a file system loop) and
that is how your software knows it is at the top.
File 5 <=== there is no path field on this printout (this file has a parent of "5")
Root Directory
$STANDARD_INFORMATION (resident)
The drive letter is not stored on the partition.
If you multiboot (have a W10 and a W11 stored on
the same SSD), then the drive lettering is stored
in each Registry, and a drive that is E: when one OS
is booted, could be F: when the other OS is booted.
I'm surprised you didn't notice the worst feature of the filesystem.
The time it takes to delete a file, has increased within the last
two years. And I have no technical note to share with you, as to why
this change was made, or, what they're doing which is so slow. Just
be aware, that in addition to the excessive calculations to "enable
a graphical animation", additional time is wasted on something we cannot
see. Even holding down the shift key when deleting, does not make
that time waster go faster. If it was part of the "Robust NTFS" program,
they would gleefully have declared that.
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.
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.
And to help you, I have explained the implementation.
On Mon, 11 Aug 2025 00:04:32 -0400, Paul wrote :
And to help you, I have explained the implementation.
Paul,
You're not normally on the Apple newsgroups, but I'm sure you're aware of
the Apple religious zealotry, which will stop at nothing to promote/defend Apple to the death.
In case you're unaware, Alan Baker is a classic Apple troll whom most of us have plonked years ago, as is David B. (although he's making a Snit-like resurgence recently) as is WolfFan & Hank Rogers - all of whom are similar.
They're all Apple religious nutcases who almost hate that Windows exists.
There's nothing wrong, per se, with them adoring their macs, but what's common with all of them is none of them know anything about Windows.
The only thing they know is what Apple marketing advertises.
They make *all* their decisions based purely on Apple advertising, in fact.
They're herd animals to the core - where they live for affirmation of their choices which themselves were dictated by Apple - and not by critical
thought processes.
Anyway, you're welcome to strive to edify them but I think it's impossible.
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.
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.
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.
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.
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
On Sun, 8/10/2025 6:33 PM, WolfFan wrote:On a Mac, just point a search at the top-level OneDrive folder and
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
Marion <marion@facts.com> wrote:
On Mon, 11 Aug 2025 00:04:32 -0400, Paul wrote :
And to help you, I have explained the implementation.
Paul,
You're not normally on the Apple newsgroups, but I'm sure you're aware of
the Apple religious zealotry, which will stop at nothing to promote/defend >> Apple to the death.
In case you're unaware, Alan Baker is a classic Apple troll whom most of us >> have plonked years ago, as is David B. (although he's making a Snit-like
resurgence recently) as is WolfFan & Hank Rogers - all of whom are similar. >>
They're all Apple religious nutcases who almost hate that Windows exists.
There's nothing wrong, per se, with them adoring their macs, but what's
common with all of them is none of them know anything about Windows.
The only thing they know is what Apple marketing advertises.
They make *all* their decisions based purely on Apple advertising, in fact. >>
They're herd animals to the core - where they live for affirmation of their >> choices which themselves were dictated by Apple - and not by critical
thought processes.
Anyway, you're welcome to strive to edify them but I think it's impossible. >>
Wrong. I don’t have a Mac and don’t want one.
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.
On 2025-08-10 23:12, Paul wrote:
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).
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
All the items appear in a flat list practically as fast as I can type it.
:-)
On Mon, 8/11/2025 2:25 PM, Alan wrote:You have now shown you lack anything resembling a clue about the topic
On 2025-08-10 23:12, Paul wrote:
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).
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
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.
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.
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.
On 2025-08-10 23:23, Hank Rogers wrote:
Marion <marion@facts.com> wrote:
On Mon, 11 Aug 2025 00:04:32 -0400, Paul wrote :
And to help you, I have explained the implementation.
Paul,
You're not normally on the Apple newsgroups, but I'm sure you're aware of >>> the Apple religious zealotry, which will stop at nothing to promote/defend >>> Apple to the death.
In case you're unaware, Alan Baker is a classic Apple troll whom most of us >>> have plonked years ago, as is David B. (although he's making a Snit-like >>> resurgence recently) as is WolfFan & Hank Rogers - all of whom are similar. >>>
They're all Apple religious nutcases who almost hate that Windows exists. >>>
There's nothing wrong, per se, with them adoring their macs, but what's
common with all of them is none of them know anything about Windows.
The only thing they know is what Apple marketing advertises.
They make *all* their decisions based purely on Apple advertising, in fact. >>>
They're herd animals to the core - where they live for affirmation of their >>> choices which themselves were dictated by Apple - and not by critical
thought processes.
Anyway, you're welcome to strive to edify them but I think it's impossible. >>>
Wrong. I don’t have a Mac and don’t want one.
And also wrong in that the "edification" Paul was attempting to provide was plainly incorrect.
:-)
You have now shown you lack anything resembling a clue about the topic of this thread.
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 calledAn inverted index is an absolute NECESSITY when searching for anything
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.
On 2025-08-10 21:04, Paul wrote:No surprise that you've address every post in this thread except this
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 ReferenceNumber, 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.
On Mon, 8/11/2025 2:26 PM, Alan wrote:In summary:
On 2025-08-10 23:23, Hank Rogers wrote:
Marion <marion@facts.com> wrote:
On Mon, 11 Aug 2025 00:04:32 -0400, Paul wrote :
And to help you, I have explained the implementation.
Paul,
You're not normally on the Apple newsgroups, but I'm sure you're aware of >>>> the Apple religious zealotry, which will stop at nothing to promote/defend >>>> Apple to the death.
In case you're unaware, Alan Baker is a classic Apple troll whom most of us
have plonked years ago, as is David B. (although he's making a Snit-like >>>> resurgence recently) as is WolfFan & Hank Rogers - all of whom are similar.
They're all Apple religious nutcases who almost hate that Windows exists. >>>>
There's nothing wrong, per se, with them adoring their macs, but what's >>>> common with all of them is none of them know anything about Windows.
The only thing they know is what Apple marketing advertises.
They make *all* their decisions based purely on Apple advertising, in fact.
They're herd animals to the core - where they live for affirmation of their
choices which themselves were dictated by Apple - and not by critical
thought processes.
Anyway, you're welcome to strive to edify them but I think it's impossible.
Wrong. I don’t have a Mac and don’t want one.
And also wrong in that the "edification" Paul was attempting to provide was plainly incorrect.
:-)
Here is an experiment carried out on an NTFS partition.
The NTFS partition is created just for this exercise -- as
a data partition, it is a bit "quieter". There are no intervening
events polluting sequences here.
*******
I started with "how do you do the equivalent of touch() in Windows".
Some AI at Google, provided this.
type nul > E:\empty.txt
The first thing I noticed, is right after this when I attempted to
read the usn journal, it did not respond. First then, I had to create
a journal.
fsutil usn createjournal [m=1000 a=100] e: # The size arguments are not required, and I used defaults
fsutil usn readjournal E: > S:\journal-output.txt # This dumps the journal so far.
This is the event which shows an example of a zero length file being created.
Usn : 0
File name : empty.txt
File name length : 18
Reason : 0x00000004: Data truncation
Time stamp : Tue, 8/12/2025 0:11:24
File attributes : 0x00000020: Archive
File ID : 00000000000000000001000000000026
Parent file ID : 00000000000000000005000000000005
Source info : 0x00000000: *NONE*
Security ID : 0
Major version : 3
Minor version : 0
Record length : 96
*******
Now that the journal is running, the first experiment is to
copy a file from the root folder, down to an arbitrary folder lower down. There are six journal entries, and this is the last entry. The event
changes seem to be ORed together in the status word. Basic info change,
might be the final size of the copied file. The nfi.exe entry shows
how the file information is stored in the Master File Table.
Copy background.bmp to A\B\C\D\E
Usn : 5584
File name : background.bmp
File name length : 28
Reason : 0x80008903: Data overwrite | Data extend | File create | Security change | Basic info change | Close
Time stamp : Tue, 8/12/2025 0:23:01
File attributes : 0x00000020: Archive
File ID : 00000000000000000001000000000033
Parent file ID : 0000000000000000000100000000002f
Source info : 0x00000000: *NONE*
Security ID : 0
Major version : 3
Minor version : 0
Record length : 104
(Insert NFI entry here)
File 51 File ID 0x33
\A\B\C\D\E\background.bmp <=== this is my copied file
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 76568-84167 (0x12b18-0x148c7)
*******
This uses the mouse to move from the root folder, to five levels down,
using two file explorer windows. As long as the balloon text next to the mouse cursor says (Move), it is being moved and not copied.
This is not an atomic event. It's two separate events. Status words
do not using the ORing scheme.
Move background2.bmp to A\B\C\D\E
Usn : 5672
File name : background2.bmp
File name length : 30
Reason : 0x00001000: Rename: old name
Time stamp : Tue, 8/12/2025 0:24:01
File attributes : 0x00000020: Archive
File ID : 00000000000000000001000000000031
Parent file ID : 00000000000000000005000000000005
Source info : 0x00000000: *NONE*
Security ID : 0
Major version : 3
Minor version : 0
Record length : 112
Usn : 5768
File name : background2.bmp
File name length : 30
Reason : 0x00002000: Rename: new name
Time stamp : Tue, 8/12/2025 0:24:01
File attributes : 0x00000020: Archive
File ID : 00000000000000000001000000000031
Parent file ID : 0000000000000000000100000000002f
Source info : 0x00000000: *NONE*
Security ID : 0
Major version : 3
Minor version : 0
Record length : 112
Usn : 5864
File name : background2.bmp
File name length : 30
Reason : 0x80002000: Rename: new name | Close
Time stamp : Tue, 8/12/2025 0:24:01
File attributes : 0x00000020: Archive
File ID : 00000000000000000001000000000031
Parent file ID : 0000000000000000000100000000002f
Source info : 0x00000000: *NONE*
Security ID : 0
Major version : 3
Minor version : 0
Record length : 112
(Insert NFI entry here) [Keeps using same Filenum entry]
File 49 File ID 0x31
\A\B\C\D\E\background2.bmp <=== this is the path after the move
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 63128-70727 (0xf698-0x11447)
*******
For the third and final experiment, we can check to see if a hardlink
was being used to implement a move. It is not. It's a separate event.
To use this to make a move() needs two journal entries, the first entry
to make-your-own move() is making the hardlink, the second operation
would be removing the original $FILE_NAME entry (which would drop the
nfi.exe entry below to having only one $FILE_NAME. Doing the move()
this way is not atomic or compact either, because it would take
two events to do it this way as well.
mklink background5.bmp to A\B\C\D\E
mklink /h E:\A\B\C\D\E\background5.bmp E:\background5.bmp
Usn : 5960
File name : background5.bmp
File name length : 30
Reason : 0x80010000: Hard link change | Close
Time stamp : Tue, 8/12/2025 0:29:24
File attributes : 0x00000020: Archive
File ID : 00000000000000000001000000000032
Parent file ID : 0000000000000000000100000000002f
Source info : 0x00000000: *NONE*
Security ID : 0
Major version : 3
Minor version : 0
Record length : 112
(Insert NFI entry here) [Adds a second $FILE_NAME to the entry, describes both hardlinked items]
File 50 File ID 0x32
\background5.bmp
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident) \___ To show how one set of clusters can have two names
$FILE_NAME (resident) /
$DATA (nonresident)
logical sectors 70728-76567 (0x11448-0x12b17)
Summary: It takes calculus to correlate the individual events
in the trace with one another. Do I personally know what
intervening events could be stuffed between events in this
trace ? I do not know.
On Mon, 8/11/2025 2:25 PM, Alan wrote:You don't actually bother reading what you're replying to...
On 2025-08-10 23:12, Paul wrote:
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).
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
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.
Windows starts with mistakes made decades ago, and
everything traces from that.
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.
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.
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.
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.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,064 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 146:18:51 |
| Calls: | 13,691 |
| Calls today: | 1 |
| Files: | 186,935 |
| D/L today: |
22 files (1,452K bytes) |
| Messages: | 2,410,869 |
