Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.mac.advocacy > #136425
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Newsgroups | comp.sys.mac.advocacy, alt.comp.os.windows-10, alt.comp.os.windows-11 |
| Subject | Re: It is stunning when you see how badly Windows operates: indexing |
| Date | 2025-08-10 17:00 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <107bbqj$26r4d$1@dont-email.me> (permalink) |
| References | <1078llp$1he7o$3@dont-email.me> <10797gb$1mdq9$1@toylet.eternal-september.org> <107adkp$1voqj$1@dont-email.me> <107ase3$22qav$1@dont-email.me> <107bb0o$27f7h$1@dont-email.me> |
Cross-posted to 3 groups.
On 2025-08-10 16:46, Paul wrote: > 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 Why is ANY of that relevant? > > ******* > > 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. > > 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. > I don't know why you've posted all of this except to deflect. > ******* > > 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. Again: why the HELL do I care about deleting files. Why can't you just admit the absurdity of a simple move of a file triggering a lengthy re-indexing process?
Back to comp.sys.mac.advocacy | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-08-09 16:30 -0700
Re: It is stunning when you see how badly Windows operates: indexing Hank Rogers <Hank@nospam.invalid> - 2025-08-09 18:55 -0500
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-08-09 17:08 -0700
Re: It is stunning when you see how badly Windows operates: indexing Hank Rogers <invalid@nospam.com> - 2025-08-10 03:22 +0000
Re: It is stunning when you see how badly Windows operates: indexing Paul <nospam@needed.invalid> - 2025-08-09 23:52 -0400
Re: It is stunning when you see how badly Windows operates: indexing "David B." <BD@hotmail.co.uk> - 2025-08-10 09:54 +0100
Re: It is stunning when you see how badly Windows operates: indexing Paul <nospam@needed.invalid> - 2025-08-09 23:28 -0400
Re: It is stunning when you see how badly Windows operates: indexing "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2025-08-10 12:34 +0800
Re: It is stunning when you see how badly Windows operates: indexing Paul <nospam@needed.invalid> - 2025-08-10 11:25 -0400
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-08-10 12:37 -0700
Re: It is stunning when you see how badly Windows operates: indexing Paul <nospam@needed.invalid> - 2025-08-10 19:46 -0400
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-08-10 17:00 -0700
Re: It is stunning when you see how badly Windows operates: indexing Paul <nospam@needed.invalid> - 2025-08-11 00:04 -0400
Re: It is stunning when you see how badly Windows operates: indexing Marion <marion@facts.com> - 2025-08-11 06:13 +0000
Re: It is stunning when you see how badly Windows operates: indexing Hank Rogers <invalid@nospam.com> - 2025-08-11 06:23 +0000
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-08-11 11:26 -0700
Re: It is stunning when you see how badly Windows operates: indexing Paul <nospam@needed.invalid> - 2025-08-12 01:15 -0400
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-08-12 08:54 -0700
Re: It is stunning when you see how badly Windows operates: indexing Paul <nospam@needed.invalid> - 2025-08-12 13:41 -0400
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-08-12 10:54 -0700
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-08-11 10:57 -0700
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-08-12 08:52 -0700
Re: It is stunning when you see how badly Windows operates: indexing "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2025-08-11 20:22 +0800
Re: It is stunning when you see how badly Windows operates: indexing Marion <marion@facts.com> - 2025-08-11 19:16 +0000
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-08-11 17:03 -0700
Re: It is stunning when you see how badly Windows operates: indexing "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2025-08-12 12:36 +0800
Re: It is stunning when you see how badly Windows operates: indexing WolfFan <akwolffan@zoho.com> - 2025-08-10 18:33 -0400
Re: It is stunning when you see how badly Windows operates: indexing Paul <nospam@needed.invalid> - 2025-08-11 02:12 -0400
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-08-11 11:25 -0700
Re: It is stunning when you see how badly Windows operates: indexing Paul <nospam@needed.invalid> - 2025-08-11 18:02 -0400
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-08-11 17:01 -0700
Re: It is stunning when you see how badly Windows operates: indexing Paul <nospam@needed.invalid> - 2025-08-12 01:24 -0400
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-08-12 08:49 -0700
Re: It is stunning when you see how badly Windows operates: indexing Marion <marion@facts.com> - 2025-08-12 17:10 +0000
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-08-12 08:55 -0700
Re: It is stunning when you see how badly Windows operates: indexing Tom Elam <thomas.e.elam@gmail.com> - 2025-08-17 16:03 -0400
Re: It is stunning when you see how badly Windows operates: indexing Paul <nospam@needed.invalid> - 2025-08-17 18:15 -0400
csiph-web