Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.comp.os.windows-10 > #186595 > unrolled thread
| Started by | Alan <nuh-uh@nope.com> |
|---|---|
| First post | 2025-08-09 16:30 -0700 |
| Last post | 2025-10-08 08:25 -0700 |
| Articles | 20 on this page of 97 — 16 participants |
Back to article view | Back to alt.comp.os.windows-10
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 Windows11 Proud User <Windows@invalid.invalid> - 2025-08-10 00:51 +0000
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 Tom Elam <thomas.e.elam@gmail.com> - 2025-10-01 14:56 -0400
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-10-01 14:08 -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 Brian Gregory <void-invalid-dead-dontuse@email.invalid> - 2025-10-06 15:49 +0100
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
Re: It is stunning when you see how badly Windows operates: indexing "Carlos E.R." <robin_listas@es.invalid> - 2025-10-01 22:19 +0200
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-10-01 14:18 -0700
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-10-05 15:01 -0700
Re: It is stunning when you see how badly Windows operates: indexing Lars Poulsen <lars@cleo.beagle-ears.com> - 2025-10-06 02:46 +0000
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-10-05 21:16 -0700
Re: It is stunning when you see how badly Windows operates: indexing Daniel70 <daniel47@nomail.afraid.org> - 2025-10-06 19:23 +1100
Re: It is stunning when you see how badly Windows operates: indexing MikeS <MikeS@fred.com> - 2025-10-06 09:56 +0100
Re: It is stunning when you see how badly Windows operates: indexing Daniel70 <daniel47@nomail.afraid.org> - 2025-10-06 20:54 +1100
Re: It is stunning when you see how badly Windows operates: indexing Brian Gregory <void-invalid-dead-dontuse@email.invalid> - 2025-10-06 15:59 +0100
Re: It is stunning when you see how badly Windows operates: indexing "Carlos E.R." <robin_listas@es.invalid> - 2025-10-06 22:35 +0200
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-10-06 13:53 -0700
Re: It is stunning when you see how badly Windows operates: indexing Daniel70 <daniel47@nomail.afraid.org> - 2025-10-08 20:12 +1100
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-10-08 08:18 -0700
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-10-06 08:59 -0700
Re: It is stunning when you see how badly Windows operates: indexing Daniel70 <daniel47@nomail.afraid.org> - 2025-10-08 20:18 +1100
Re: It is stunning when you see how badly Windows operates: indexing "J. P. Gilliver" <G6JPG@255soft.uk> - 2025-10-08 11:16 +0100
Re: It is stunning when you see how badly Windows operates: indexing MikeS <MikeS@fred.com> - 2025-10-06 17:28 +0100
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-10-06 09:33 -0700
Re: It is stunning when you see how badly Windows operates: indexing Daniel70 <daniel47@nomail.afraid.org> - 2025-10-08 20:23 +1100
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-10-08 08:20 -0700
Re: It is stunning when you see how badly Windows operates: indexing "Carlos E.R." <robin_listas@es.invalid> - 2025-10-06 14:22 +0200
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-10-06 09:00 -0700
Re: It is stunning when you see how badly Windows operates: indexing Daniel70 <daniel47@nomail.afraid.org> - 2025-10-08 20:30 +1100
Re: It is stunning when you see how badly Windows operates: indexing "Carlos E.R." <robin_listas@es.invalid> - 2025-10-08 11:48 +0200
Re: It is stunning when you see how badly Windows operates: indexing "J. P. Gilliver" <G6JPG@255soft.uk> - 2025-10-08 11:25 +0100
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-10-08 08:22 -0700
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-10-08 08:21 -0700
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-10-08 08:20 -0700
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-10-06 08:58 -0700
Re: It is stunning when you see how badly Windows operates: indexing "Carlos E.R." <robin_listas@es.invalid> - 2025-10-06 22:44 +0200
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-10-06 13:56 -0700
Re: It is stunning when you see how badly Windows operates: indexing "Carlos E.R." <robin_listas@es.invalid> - 2025-10-06 23:22 +0200
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-10-06 16:51 -0700
Re: It is stunning when you see how badly Windows operates: indexing Daniel70 <daniel47@nomail.afraid.org> - 2025-10-08 20:35 +1100
Re: It is stunning when you see how badly Windows operates: indexing "J. P. Gilliver" <G6JPG@255soft.uk> - 2025-10-08 11:38 +0100
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-10-08 08:23 -0700
Re: It is stunning when you see how badly Windows operates: indexing Paul <nospam@needed.invalid> - 2025-10-06 04:52 -0400
Re: It is stunning when you see how badly Windows operates: indexing "Carlos E.R." <robin_listas@es.invalid> - 2025-10-06 14:17 +0200
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-10-06 09:12 -0700
Re: It is stunning when you see how badly Windows operates: indexing "Carlos E.R." <robin_listas@es.invalid> - 2025-10-06 22:47 +0200
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-10-06 14:12 -0700
Re: It is stunning when you see how badly Windows operates: indexing "Carlos E.R." <robin_listas@es.invalid> - 2025-10-06 23:25 +0200
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-10-06 16:55 -0700
Re: It is stunning when you see how badly Windows operates: indexing Daniel70 <daniel47@nomail.afraid.org> - 2025-10-08 21:21 +1100
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-10-08 08:24 -0700
Re: It is stunning when you see how badly Windows operates: indexing Brian Gregory <void-invalid-dead-dontuse@email.invalid> - 2025-10-06 15:45 +0100
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-10-06 09:13 -0700
Re: It is stunning when you see how badly Windows operates: indexing Brian Gregory <void-invalid-dead-dontuse@email.invalid> - 2025-10-06 17:48 +0100
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-10-06 10:08 -0700
Re: It is stunning when you see how badly Windows operates: indexing Paul <nospam@needed.invalid> - 2025-10-06 19:51 -0400
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-10-06 17:27 -0700
Re: It is stunning when you see how badly Windows operates: indexing Paul <nospam@needed.invalid> - 2025-10-06 21:47 -0400
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-10-06 22:13 -0700
Re: It is stunning when you see how badly Windows operates: indexing Daniel70 <daniel47@nomail.afraid.org> - 2025-10-08 22:01 +1100
Re: It is stunning when you see how badly Windows operates: indexing Paul <nospam@needed.invalid> - 2025-10-08 10:45 -0400
Re: It is stunning when you see how badly Windows operates: indexing Alan <nuh-uh@nope.com> - 2025-10-08 08:25 -0700
Page 1 of 5 [1] 2 3 4 5 Next page →
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Date | 2025-08-09 16:30 -0700 |
| Subject | It is stunning when you see how badly Windows operates: indexing |
| Message-ID | <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.
[toc] | [next] | [standalone]
| From | Hank Rogers <Hank@nospam.invalid> |
|---|---|
| Date | 2025-08-09 18:55 -0500 |
| Message-ID | <1078n51$1j6tj$7@dont-email.me> |
| In reply to | #186595 |
Alan wrote on 8/9/2025 6:30 PM: > 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.
[toc] | [prev] | [next] | [standalone]
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Date | 2025-08-09 17:08 -0700 |
| Message-ID | <1078nu5$1he2o$6@dont-email.me> |
| In reply to | #186597 |
On 2025-08-09 16:55, Hank Rogers wrote: > Alan wrote on 8/9/2025 6:30 PM: >> 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. Believe me, I have. 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. :-)
[toc] | [prev] | [next] | [standalone]
| From | Windows11 Proud User <Windows@invalid.invalid> |
|---|---|
| Date | 2025-08-10 00:51 +0000 |
| Message-ID | <1078qo5$3j0r0$1@paganini.bofh.team> |
| In reply to | #186598 |
On 10/08/2025 01:08, Alan wrote: > his next machine just might be a Mac Why a Mac? Why not use some other terrible operating system, like Linux?! If you're not using Windows or you don't like how it works, then go and fuck yourself. Windows is different, which is why almost everyone uses it.
[toc] | [prev] | [next] | [standalone]
| From | Hank Rogers <invalid@nospam.com> |
|---|---|
| Date | 2025-08-10 03:22 +0000 |
| Message-ID | <107939n$1lmqg$1@dont-email.me> |
| In reply to | #186598 |
Alan <nuh-uh@nope.com> wrote: > On 2025-08-09 16:55, Hank Rogers wrote: >> Alan wrote on 8/9/2025 6:30 PM: >>> 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. > Believe me, I have. > > 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.
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-08-09 23:52 -0400 |
| Message-ID | <107952b$1m06l$1@dont-email.me> |
| In reply to | #186601 |
On 08/09/25 23:22, Hank Rogers wrote: > Alan <nuh-uh@nope.com> wrote: >> On 2025-08-09 16:55, Hank Rogers wrote: >>> Alan wrote on 8/9/2025 6:30 PM: >>>> 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. >> Believe me, I have. >> >> 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. It's a good thing Alan has not picked up on the really bad parts of Windows :-) 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. Paul
[toc] | [prev] | [next] | [standalone]
| From | "David B." <BD@hotmail.co.uk> |
|---|---|
| Date | 2025-08-10 09:54 +0100 |
| Message-ID | <mfr52pFko2cU1@mid.individual.net> |
| In reply to | #186603 |
On 10/08/2025 04:52, Paul wrote: [....] > 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. When was the last time you used an Apple computer, Paul? In which web fora did you help out? (Did I tell you that Philo died? Like you, he was a GOOD man.)
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-08-09 23:28 -0400 |
| Message-ID | <10793lo$1lome$1@dont-email.me> |
| In reply to | #186595 |
On 08/09/25 19:30, 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.
As a surprise for you, the people in the Windows groups
you copied in, don't actually recommended the Federated Search.
The model is pretty easy to understand. The NTFS USN Journal file
(NTFS is a journaled file system with a playback journal), every
time *any* file operation is done, a record is added to a FIFO queue
of events. For example, I can createfile(test.txt), writefile(256KB, "test.txt"),
commit("test.txt") and so on. I have a history of the file, its size as
it "grows" during writes, and there should be some record of when the
file is done and flushed.
The USN Journal offers a service, where each entry of that style,
is "sent" to applications that register for the broadcast service.
For example, Windows Search Indexer registers for all the NTFS USN Journals,
and people who have installed third-party "Everything.exe" or
"File Locator Pro" (Mythic Software), those applications also keep their
file lists current (additions, deletions, moves, copies) bu listening for
the broadcasts and applying their filter(s) so they can ignore any exclusion
zones.
The Search Indexer has two options (filename, content) indexing
or just (filename) indexing. We're not sure whether the ticky box for
"filename only" indexing has ever worked. If all the Search Indexer did
was filename indexing, it would finish a lot faster than if indexing
Content. Whether the box is ticked or cleared, the database contains
a content index. Typical database size is 4GB.
You can define Exclusions, to keep the Gatherer out of certain folders.
For example, WinSxS would be a poor choice of areas to index,
similarly indexing the OS "LCU" Last Cumulative Update folder on
Windows 10, that would be a piss poor choice of places to Index.
There can be 200,000 files nobody cares about in LCU.
This is a power user feature, that requires an investment in tuning
to reap a result. It took me *forever* to tune Windows 7, but for
some reason today, the Windows 7 search is pretty well instant. I
don't even understand how that is possible, because I was driving
the search with a script for a while (as part of testing and to
get rid of File Explorer bloat from ruining the result), and at
one time, it could never return a result in under three seconds.
Now, without patches or updates, it beats its old record.
1) There is a lot of mystery meat in Federated Search.
2) Federated Search recommended-max file count is 1,000,000 files.
Failure to observe this, it just means the Merge operations
the Indexer does, get slower and slower. Inverted Search indexers,
tend to index a set of files, and then they Merge the smaller index
into the Master index. And this is a miserably slow way to do it,
but more than one company does it this way.
3) Third party tools are willing to do filename-only indexing, which
can be a lot faster than (filename,content) indexing. I can't speak
for others, on the perceived performance of the third party ones.
I've tested Indexing, but I'm not making a fetish of this, and I needed
it to work on the Windows 7 Archive setup, as that's my NAS. I defined
some exclusions. There are still a few things I should be excluding
which haven't been added.
For my Daily Driver, I use Agent Ransack brute force searcher.
Search time is at least consistent, and there is a tendency to
not miss files when I use Agent Ransack. For the Federated Search,
there is some quirky behavior when entering names. For example
filename:"*test*"
will give you a more precise result than
test
entered without proper syntax. You can also do things
like that without the double quotes, but there might
be some exposure by doing so. I'm pretty sure some formulation
of a file name, will run afoul of this one, and the file won't
be picked up.
filename:*test*
You can name things and AND them together.
filename:*test* ext:txt content:"Hello World"
So one of the things it would be handy to find, would be
the web page with the "search language" that works this week.
You would think a piece of crap this complicated, would
have a Help file... Ha!
Paul (sent from alternate OS, experiment...)
[toc] | [prev] | [next] | [standalone]
| From | "Mr. Man-wai Chang" <toylet.toylet@gmail.com> |
|---|---|
| Date | 2025-08-10 12:34 +0800 |
| Message-ID | <10797gb$1mdq9$1@toylet.eternal-september.org> |
| In reply to | #186595 |
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?? :) -- @~@ 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]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-08-10 11:25 -0400 |
| Message-ID | <107adkp$1voqj$1@dont-email.me> |
| In reply to | #186604 |
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
Paul
[toc] | [prev] | [next] | [standalone]
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Date | 2025-08-10 12:37 -0700 |
| Message-ID | <107ase3$22qav$1@dont-email.me> |
| In reply to | #186623 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-08-10 19:46 -0400 |
| Message-ID | <107bb0o$27f7h$1@dont-email.me> |
| In reply to | #186635 |
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
[toc] | [prev] | [next] | [standalone]
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Date | 2025-08-10 17:00 -0700 |
| Message-ID | <107bbqj$26r4d$1@dont-email.me> |
| In reply to | #186637 |
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?
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-08-11 00:04 -0400 |
| Message-ID | <107bq4h$2ah49$1@dont-email.me> |
| In reply to | #186638 |
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
[toc] | [prev] | [next] | [standalone]
| From | Marion <marion@facts.com> |
|---|---|
| Date | 2025-08-11 06:13 +0000 |
| Message-ID | <107c1lq$27jk$1@nnrp.usenet.blueworldhosting.com> |
| In reply to | #186646 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Hank Rogers <invalid@nospam.com> |
|---|---|
| Date | 2025-08-11 06:23 +0000 |
| Message-ID | <107c285$2c32t$1@dont-email.me> |
| In reply to | #186648 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Date | 2025-08-11 11:26 -0700 |
| Message-ID | <107dckr$2nolj$7@dont-email.me> |
| In reply to | #186649 |
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. :-)
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-08-12 01:15 -0400 |
| Message-ID | <107eim1$32gtq$1@dont-email.me> |
| In reply to | #186671 |
On Mon, 8/11/2025 2:26 PM, Alan wrote:
> 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.
Paul
[toc] | [prev] | [next] | [standalone]
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Date | 2025-08-12 08:54 -0700 |
| Message-ID | <107fo2v$3bn97$3@dont-email.me> |
| In reply to | #186697 |
On 2025-08-11 22:15, Paul wrote: > On Mon, 8/11/2025 2:26 PM, Alan wrote: >> 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. 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.
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-08-12 13:41 -0400 |
| Message-ID | <107fubq$3el5o$1@dont-email.me> |
| In reply to | #186711 |
On Tue, 8/12/2025 11:54 AM, Alan wrote:
> In summary:
>
> You claimed that moving a file generated a deletefile entry and a createfile entry in the USN journal...
>
> ...and you've just shown that to be bullshit.
I regret to inform you, that the output of this utility
is NOT THE SAME AS THE OTHER TIME I RAN IT.
For example, previously, as a file was written, there were incremental
size events recorded for some reason. Those are missing from the trace now.
Can you imagine ? An OS first released in 2015 and it is now 2025,
and something has changed ? While the NTFS API revision number has
not changed, the design of the file system has changed and is not
backward compatible (max cluster size in W10 can't be mounted by Win7).
The fsutil utility is an instance of utility that parses journal entries.
There is no guarantee it is good or better than other examples of parsers
written to analyze the thing.
The point is, unless a single journal event has sufficient
self-contained metadata for some calculus, there won't be any calculus.
They're not going to sift through the events in there, until they
have enough to perform some magic.
I tried an experiment this morning, to make it more efficient,
and what that did, is take an all day run to index C: and reduce
that to two hours or so. It did not speed up all that much, and
the inverted index file was still large. I tried searching for
all images on the Test Machine with width:>0
and it reported 75000 images but then it kinda froze (the progress
bar on it stopped moving).
It's just clunky software, and as I indicated before, nobody here
particular cares about it or cares for it, using third-party
tools instead which are more predictable. Sometimes you get
lucky with the federated search and it works quickly, but it could
take many indexing tries before it settles down. Originally, it exhibited
looping behavior, where the count of files would go up and down by
1 file count (keeping the CPU working on it). My working instance
of it (Windows 7), is not looping like that now.
I would be a lot happier, if I could tell you how to turn it off,
but Microsoft is using it for some purpose of their own, and it
could only be stopped by removing executables and moves of that sort.
There is no button to switch it off, or I'd have switched it off on
most of my installs here by now. If you kill it in Task Manager
("SearchIndexer.exe"), it restarts, and it does not follow a three strikes
rule either, it will just keep restarting, with variable intervals
for the restart. The restart time can be as short as one second.
Or as long as minutes.
This is why it's not a fetish topic, it is not reliable enough for
daily use, and other tools work when you use them.
The inverted index design is not all that unusual. I got my first
taste of one of those on Adobe Distiller 4 late in Win98. It has
an inverted index for searching PDF files, and it uses the
merge small sets of files into the Master Index method too, once
the index gets to a certain size. And the Adobe indexer was also
dreadfully slow. The Microsoft behavior is not all that different.
There are other kinds of databases for storing filenames, that
are going to be a lot faster than an inverted content index
(which is what an Everything.exe or a File Locator Pro would use).
Even when the index is told to not store content, it still
stores the metadata as if it was content (the size of the index
file doesn't exactly get smaller).
*******
Since the playback journal works hand in glove with file system recovery,
if the recovery method changes, what is collected in the journal has to match.
That is one purpose it has to meet. The design would change, in the same
way as other things changed, to reduce wear on SSD drives. That's why some
of this evolution is going on.
A secondary purpose is for broadcasting file changes to utilities for file tracking purpose.
As an example of another change, the file buffering on file handles changed,
such that writes are buffered to 64K and the writer will not write just one
cluster when one cluster is ready. If the file is closed, then any remaining
material in the buffer is flushed. I first noticed this on a fragmenter tool.
At one time, it would make 4K fragments for me. Then on a later OS, it would
only make 64K fragments (and the code for that utility had not changed).
There are constantly changes like this going on in the OS, without
anyone being informed of it. You make observations as best you can,
to keep track.
Paul
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | alt.comp.os.windows-10
csiph-web