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

Groups > comp.sys.mac.advocacy > #136424

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

Cross-posted to 3 groups.

Show all headers | View raw

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:
>>> 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 sorry, but it does matter how cleverly and well the OS is coded to do the indexing.
> 
> 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.

*******

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.

   Paul

Back to comp.sys.mac.advocacy | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

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