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 | 17 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 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-10-06 22:47 +0200 |
| Message-ID | <afmdrlxueb.ln2@Telcontar.valinor> |
| In reply to | #188008 |
On 2025-10-06 18:12, Alan wrote: > On 2025-10-06 05:17, Carlos E.R. wrote: >> On 2025-10-06 06:16, Alan wrote: >>> Move the file and all you need to do is update that one piece of >>> information. >> >> For that you need a system service that tracks moves and tells the >> indexer. It doesn't happen automatically. >> > > And why would that be at all difficult? > > You have a journaled file system, so all you need is a process that > checks for events in the journal that actually DO mean that there is a > new file that's been created or that a file has been changed. > > Those events require that a file get re-indexed. Moving a file within > the same volume does NOT. > > That process on macOS is called "fseventsd" > > Look it up. Not going to look it up, I don't do macs. I'll accept your word. Does Windows do it? -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Date | 2025-10-06 14:12 -0700 |
| Message-ID | <10c1bcb$he84$3@dont-email.me> |
| In reply to | #188023 |
On 2025-10-06 13:47, Carlos E.R. wrote: > On 2025-10-06 18:12, Alan wrote: >> On 2025-10-06 05:17, Carlos E.R. wrote: >>> On 2025-10-06 06:16, Alan wrote: >>>> Move the file and all you need to do is update that one piece of >>>> information. >>> >>> For that you need a system service that tracks moves and tells the >>> indexer. It doesn't happen automatically. >>> >> >> And why would that be at all difficult? >> >> You have a journaled file system, so all you need is a process that >> checks for events in the journal that actually DO mean that there is a >> new file that's been created or that a file has been changed. >> >> Those events require that a file get re-indexed. Moving a file within >> the same volume does NOT. >> >> That process on macOS is called "fseventsd" >> >> Look it up. > > Not going to look it up, I don't do macs. I'll accept your word. > > Does Windows do it? Apparently not. Which is why I wrote subject I did: "It is stunning when you see how badly Windows operates: indexing"
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-10-06 23:25 +0200 |
| Message-ID | <smodrlxelg.ln2@Telcontar.valinor> |
| In reply to | #188026 |
On 2025-10-06 23:12, Alan wrote: > On 2025-10-06 13:47, Carlos E.R. wrote: >> On 2025-10-06 18:12, Alan wrote: >>> On 2025-10-06 05:17, Carlos E.R. wrote: >>>> On 2025-10-06 06:16, Alan wrote: >>>>> Move the file and all you need to do is update that one piece of >>>>> information. >>>> >>>> For that you need a system service that tracks moves and tells the >>>> indexer. It doesn't happen automatically. >>>> >>> >>> And why would that be at all difficult? >>> >>> You have a journaled file system, so all you need is a process that >>> checks for events in the journal that actually DO mean that there is >>> a new file that's been created or that a file has been changed. >>> >>> Those events require that a file get re-indexed. Moving a file within >>> the same volume does NOT. >>> >>> That process on macOS is called "fseventsd" >>> >>> Look it up. >> >> Not going to look it up, I don't do macs. I'll accept your word. >> >> Does Windows do it? > > Apparently not. > > Which is why I wrote subject I did: > > "It is stunning when you see how badly Windows operates: indexing" Well, I know that I have moved in the past huge content in Linux and seen several content indexers re-index them. I would have to test again noticing if it was the same partition. -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Date | 2025-10-06 16:55 -0700 |
| Message-ID | <10c1ktg$kair$2@dont-email.me> |
| In reply to | #188028 |
On 2025-10-06 14:25, Carlos E.R. wrote: > On 2025-10-06 23:12, Alan wrote: >> On 2025-10-06 13:47, Carlos E.R. wrote: >>> On 2025-10-06 18:12, Alan wrote: >>>> On 2025-10-06 05:17, Carlos E.R. wrote: >>>>> On 2025-10-06 06:16, Alan wrote: >>>>>> Move the file and all you need to do is update that one piece of >>>>>> information. >>>>> >>>>> For that you need a system service that tracks moves and tells the >>>>> indexer. It doesn't happen automatically. >>>>> >>>> >>>> And why would that be at all difficult? >>>> >>>> You have a journaled file system, so all you need is a process that >>>> checks for events in the journal that actually DO mean that there is >>>> a new file that's been created or that a file has been changed. >>>> >>>> Those events require that a file get re-indexed. Moving a file >>>> within the same volume does NOT. >>>> >>>> That process on macOS is called "fseventsd" >>>> >>>> Look it up. >>> >>> Not going to look it up, I don't do macs. I'll accept your word. >>> >>> Does Windows do it? >> >> Apparently not. >> >> Which is why I wrote subject I did: >> >> "It is stunning when you see how badly Windows operates: indexing" > > Well, I know that I have moved in the past huge content in Linux and > seen several content indexers re-index them. I would have to test again > noticing if it was the same partition. A move to another volume is never really a move, now is it? The OS can make the end result appear to be the SAME as a move, but if you want the files on a different volume, then the data in those files will have to be WRITTEN to that new volume and of course the indexing for that volume will have no entries for those files... ...because from the context of that new volume… ...THEY WILL BE NEW FILES.
[toc] | [prev] | [next] | [standalone]
| From | Daniel70 <daniel47@nomail.afraid.org> |
|---|---|
| Date | 2025-10-08 21:21 +1100 |
| Message-ID | <10c5duk$1h6mr$1@dont-email.me> |
| In reply to | #188031 |
On 7/10/2025 10:55 am, Alan wrote: > On 2025-10-06 14:25, Carlos E.R. wrote: >> On 2025-10-06 23:12, Alan wrote: >>> On 2025-10-06 13:47, Carlos E.R. wrote: >>>> On 2025-10-06 18:12, Alan wrote: >>>>> On 2025-10-06 05:17, Carlos E.R. wrote: >>>>>> On 2025-10-06 06:16, Alan wrote: >>>>>>> Move the file and all you need to do is update that one piece of >>>>>>> information. >>>>>> >>>>>> For that you need a system service that tracks moves and tells the >>>>>> indexer. It doesn't happen automatically. >>>>> >>>>> And why would that be at all difficult? >>>>> >>>>> You have a journaled file system, so all you need is a process that >>>>> checks for events in the journal that actually DO mean that there >>>>> is a new file that's been created or that a file has been changed. >>>>> >>>>> Those events require that a file get re-indexed. Moving a file >>>>> within the same volume does NOT. >>>>> >>>>> That process on macOS is called "fseventsd" >>>>> >>>>> Look it up. >>>> >>>> Not going to look it up, I don't do macs. I'll accept your word. >>>> >>>> Does Windows do it? >>> >>> Apparently not. >>> >>> Which is why I wrote subject I did: >>> >>> "It is stunning when you see how badly Windows operates: indexing" >> >> Well, I know that I have moved in the past huge content in Linux and >> seen several content indexers re-index them. I would have to test >> again noticing if it was the same partition. > A move to another volume is never really a move, now is it? > > The OS can make the end result appear to be the SAME as a move, but if > you want the files on a different volume, then the data in those files > will have to be WRITTEN to that new volume and of course the indexing > for that volume will have no entries for those files... > > ...because from the context of that new volume… > > ...THEY WILL BE NEW FILES. So when DO those files that YOU have WRITTEN to that new volume actually get listed in the content of that new volume?? And when do they get deleted from the original volume .... and de-Indexed, of course?? -- Daniel70
[toc] | [prev] | [next] | [standalone]
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Date | 2025-10-08 08:24 -0700 |
| Message-ID | <10c5vna$1m1kq$7@dont-email.me> |
| In reply to | #188084 |
On 2025-10-08 03:21, Daniel70 wrote: > On 7/10/2025 10:55 am, Alan wrote: >> On 2025-10-06 14:25, Carlos E.R. wrote: >>> On 2025-10-06 23:12, Alan wrote: >>>> On 2025-10-06 13:47, Carlos E.R. wrote: >>>>> On 2025-10-06 18:12, Alan wrote: >>>>>> On 2025-10-06 05:17, Carlos E.R. wrote: >>>>>>> On 2025-10-06 06:16, Alan wrote: >>>>>>>> Move the file and all you need to do is update that one piece of >>>>>>>> information. >>>>>>> >>>>>>> For that you need a system service that tracks moves and tells >>>>>>> the indexer. It doesn't happen automatically. >>>>>> >>>>>> And why would that be at all difficult? >>>>>> >>>>>> You have a journaled file system, so all you need is a process >>>>>> that checks for events in the journal that actually DO mean that >>>>>> there is a new file that's been created or that a file has been >>>>>> changed. >>>>>> >>>>>> Those events require that a file get re-indexed. Moving a file >>>>>> within the same volume does NOT. >>>>>> >>>>>> That process on macOS is called "fseventsd" >>>>>> >>>>>> Look it up. >>>>> >>>>> Not going to look it up, I don't do macs. I'll accept your word. >>>>> >>>>> Does Windows do it? >>>> >>>> Apparently not. >>>> >>>> Which is why I wrote subject I did: >>>> >>>> "It is stunning when you see how badly Windows operates: indexing" >>> >>> Well, I know that I have moved in the past huge content in Linux and >>> seen several content indexers re-index them. I would have to test >>> again noticing if it was the same partition. >> A move to another volume is never really a move, now is it? >> >> The OS can make the end result appear to be the SAME as a move, but if >> you want the files on a different volume, then the data in those files >> will have to be WRITTEN to that new volume and of course the indexing >> for that volume will have no entries for those files... >> >> ...because from the context of that new volume… >> >> ...THEY WILL BE NEW FILES. > > So when DO those files that YOU have WRITTEN to that new volume actually > get listed in the content of that new volume?? > > And when do they get deleted from the original volume .... and de- > Indexed, of course?? You're too ignorant to be in this conversation.
[toc] | [prev] | [next] | [standalone]
| From | Brian Gregory <void-invalid-dead-dontuse@email.invalid> |
|---|---|
| Date | 2025-10-06 15:45 +0100 |
| Message-ID | <mki30dF49p4U1@mid.individual.net> |
| In reply to | #186595 |
On 10/08/2025 00: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. Surely most people just turn indexing off. It's pretty useless anyway. But you can leave it on if you have an SSD without it causing too much of a problem. -- Brian Gregory (in England).
[toc] | [prev] | [next] | [standalone]
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Date | 2025-10-06 09:13 -0700 |
| Message-ID | <10c0pr7$d6mu$5@dont-email.me> |
| In reply to | #188000 |
On 2025-10-06 07:45, Brian Gregory wrote: > On 10/08/2025 00: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. > > Surely most people just turn indexing off. Not on macOS. > It's pretty useless anyway. Just on Windows. > But you can leave it on if you have an SSD without it causing too much > of a problem. Or you could use a decent operating system.
[toc] | [prev] | [next] | [standalone]
| From | Brian Gregory <void-invalid-dead-dontuse@email.invalid> |
|---|---|
| Date | 2025-10-06 17:48 +0100 |
| Message-ID | <mkia67F5gnmU1@mid.individual.net> |
| In reply to | #188009 |
On 06/10/2025 17:13, Alan wrote: > On 2025-10-06 07:45, Brian Gregory wrote: >> On 10/08/2025 00: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. >> >> Surely most people just turn indexing off. > > Not on macOS. > >> It's pretty useless anyway. > > Just on Windows. > >> But you can leave it on if you have an SSD without it causing too much >> of a problem. > Or you could use a decent operating system. If you'll buy me new Linux or Mac versions of all my software I'd be glad to try a better OS. What kind of brain dead person needs to search everything on their hard drive for that one document then mentioned that one thing that they miraculously remember the name of while they mysteriously completely forget when or where on their computer it was mentioned, yet somehow they managed to remember it was on their computer they saw it rather than on TV or in the Newspaper. -- Brian Gregory (in England).
[toc] | [prev] | [next] | [standalone]
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Date | 2025-10-06 10:08 -0700 |
| Message-ID | <10c0t33$ec9j$1@dont-email.me> |
| In reply to | #188014 |
On 2025-10-06 09:48, Brian Gregory wrote: > On 06/10/2025 17:13, Alan wrote: >> On 2025-10-06 07:45, Brian Gregory wrote: >>> On 10/08/2025 00: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. >>> >>> Surely most people just turn indexing off. >> >> Not on macOS. >> >>> It's pretty useless anyway. >> >> Just on Windows. >> >>> But you can leave it on if you have an SSD without it causing too >>> much of a problem. >> Or you could use a decent operating system. > > If you'll buy me new Linux or Mac versions of all my software I'd be > glad to try a better OS. > > What kind of brain dead person needs to search everything on their hard > drive for that one document then mentioned that one thing that they > miraculously remember the name of while they mysteriously completely > forget when or where on their computer it was mentioned, yet somehow > they managed to remember it was on their computer they saw it rather > than on TV or in the Newspaper. Why wouldn't you WANT TO BE ABLE TO when necessary? This system is seamless and it also provides the basis for the macOS backup system.
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-10-06 19:51 -0400 |
| Message-ID | <10c1kms$knib$1@dont-email.me> |
| In reply to | #188000 |
On Mon, 10/6/2025 10:45 AM, Brian Gregory wrote:
> On 10/08/2025 00: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.
>
> Surely most people just turn indexing off.
> It's pretty useless anyway.
> But you can leave it on if you have an SSD without it causing too much of a problem.
>
How the Indexer works, is going to depend on how the Change Journal works.
The Indexer is not a 60 line program and a "tight ball of code". There
are three running processes in Task Manager for the operation of it. It's
rather big, as packaging goes. The processes even run with different
priorities (one runs at a lower priority setting than the others and
gets trashed and restarted every once in a while).
*******
Doing operations on the file system, developers are able to get different
levels of performance. The NFI.exe utility from Microsoft, is my "go to"
utility when I must know what is in a partition. It was written in the
year 2003, and badly needs an update to be written (in particular, the
$FILE_NAME entry, the string stored in there needs to be printed on
the screen and that is missing information). Files which have multiple
$FILE_NAME, are hardlinked files. Notice here, how I am able to find
the Windows 11 Search Indexer inverted index file. It is stored on the
file system as Filenum 23838 and is lightly fragmented.
.\nfi C: > nfi-C-out.txt # And, 145 seconds later... 210MB listing 2,771,720 lines
File 23838
\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.db
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 33709448-33712863 (0x2025d88-0x2026adf)
... (30 fragments total) (early search Index had hundreds of fragments)
logical sectors 91984216-91984239 (0x57b9158-0x57b916f)
The Indexer file is 2.35MB in size, as the Indexer in this machine is not configured
to index anything..
Now compare that to a VoidTool Everything.exe attempt to list a file system.
Everything.exe does an "initial index" at machine startup, and you can tap into
that by using the utiity without all of its baggage ("one-shot" utility usage).
Now, it's not always this fast, but this is a good demo.
.\Everything.exe -create-filelist every_c.txt "C:" # Examine the text file, to see the metadata
# they keep in there. This emulates the initial
# indexing process. You cannot list the WsL1 tree
# files this way, they are ignored. Neither would
# it pretend to access System Volume Information files.
# There are safety reasons for staying out of there.
7 seconds, 56,985,788 bytes output 360,000 lines or so. Entries for five files shown.
Filename, Size, Date Modified, Date Created, Attributes
"C:\Users\paul\Downloads\Windows-universal-samples-main--includes-OCR-sample.zip",28899211,133659001969022138,134034795503869343,32
"C:\Users\paul\Downloads\windows10.0-kb5034232-x64_SafeOS-WinRE-example.cab",7530358,133696434360300569,134034795502291984,32
"C:\Users\paul\Downloads\Windows10Upgrade9252.exe",3343496,133195821885381788,134034795502453969,32
"C:\Users\paul\Downloads\Windows11Upgrade_EN.zip",409341,132937705786434792,134034795502762944,32
"C:\Users\paul\Downloads\Windows6.1-KB3004394-v2-x64.msu",2442957,132894276659630869,134034795501816348,32
That code then, has different objectives, but the code is 20x faster in the example.
The very first version of the Voidtools work, did that job in *2* seconds, but back then
all you got was a filename absolute path (no numbers on the end).
The Content Indexing that Microsoft does, is a mondo bloat thing to do.
It's orders of magnitude slower, and it takes all day to Content Index my
"NAS collection".
The Content Indexer is recommended to not be indexing more than 1 million files.
That's what Microsoft specs as a practical limit. You can drive it harder
than that, but expect some aspect to be slower.
Summary: No one in their right mind uses the search box in File Explorer.
How many times has it missed stuff ? You decide.
But there are signs that maintainers still fiddle around with
the implementation. In Win10 it uses Windows.edb "Jet Blue" database.
In Win11 it uses Windows.db SQLite3 database. This makes no different
at the user level (and isn't this why we write code???).
I think if we had a Change Journal expert here, we could get an answer
on how file moves are encoded, how many entries such an activity would
span, and whether an architecture would allow optimization for it.
It's the same when a naive person watches the miserably slow file deletion.
The person would say "hey, why not stop the computer for a second,
total up all the changes to the $MFT and just blast them in as a huge edit".
and that causes a huge explanation of why we can't/won't be doing that.
If that was even remotely possible, we'd have done it by now. Or at least,
there would be a credible explanation of how we could do it.
Paul
[toc] | [prev] | [next] | [standalone]
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Date | 2025-10-06 17:27 -0700 |
| Message-ID | <10c1mor$l2dr$1@dont-email.me> |
| In reply to | #188030 |
On 2025-10-06 16:51, Paul wrote:
> On Mon, 10/6/2025 10:45 AM, Brian Gregory wrote:
>> On 10/08/2025 00: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.
>>
>> Surely most people just turn indexing off.
>> It's pretty useless anyway.
>> But you can leave it on if you have an SSD without it causing too much of a problem.
>>
>
> How the Indexer works, is going to depend on how the Change Journal works.
> The Indexer is not a 60 line program and a "tight ball of code". There
> are three running processes in Task Manager for the operation of it. It's
> rather big, as packaging goes. The processes even run with different
> priorities (one runs at a lower priority setting than the others and
> gets trashed and restarted every once in a while).
>
> *******
>
> Doing operations on the file system, developers are able to get different
> levels of performance. The NFI.exe utility from Microsoft, is my "go to"
> utility when I must know what is in a partition. It was written in the
> year 2003, and badly needs an update to be written (in particular, the
> $FILE_NAME entry, the string stored in there needs to be printed on
> the screen and that is missing information). Files which have multiple
> $FILE_NAME, are hardlinked files. Notice here, how I am able to find
> the Windows 11 Search Indexer inverted index file. It is stored on the
> file system as Filenum 23838 and is lightly fragmented.
>
> .\nfi C: > nfi-C-out.txt # And, 145 seconds later... 210MB listing 2,771,720 lines
>
> File 23838
> \ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.db
>
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (nonresident)
> logical sectors 33709448-33712863 (0x2025d88-0x2026adf)
> ... (30 fragments total) (early search Index had hundreds of fragments)
> logical sectors 91984216-91984239 (0x57b9158-0x57b916f)
>
> The Indexer file is 2.35MB in size, as the Indexer in this machine is not configured
> to index anything..
>
> Now compare that to a VoidTool Everything.exe attempt to list a file system.
> Everything.exe does an "initial index" at machine startup, and you can tap into
> that by using the utiity without all of its baggage ("one-shot" utility usage).
> Now, it's not always this fast, but this is a good demo.
>
> .\Everything.exe -create-filelist every_c.txt "C:" # Examine the text file, to see the metadata
> # they keep in there. This emulates the initial
> # indexing process. You cannot list the WsL1 tree
> # files this way, they are ignored. Neither would
> # it pretend to access System Volume Information files.
> # There are safety reasons for staying out of there.
>
> 7 seconds, 56,985,788 bytes output 360,000 lines or so. Entries for five files shown.
>
> Filename, Size, Date Modified, Date Created, Attributes
> "C:\Users\paul\Downloads\Windows-universal-samples-main--includes-OCR-sample.zip",28899211,133659001969022138,134034795503869343,32
> "C:\Users\paul\Downloads\windows10.0-kb5034232-x64_SafeOS-WinRE-example.cab",7530358,133696434360300569,134034795502291984,32
> "C:\Users\paul\Downloads\Windows10Upgrade9252.exe",3343496,133195821885381788,134034795502453969,32
> "C:\Users\paul\Downloads\Windows11Upgrade_EN.zip",409341,132937705786434792,134034795502762944,32
> "C:\Users\paul\Downloads\Windows6.1-KB3004394-v2-x64.msu",2442957,132894276659630869,134034795501816348,32
>
> That code then, has different objectives, but the code is 20x faster in the example.
> The very first version of the Voidtools work, did that job in *2* seconds, but back then
> all you got was a filename absolute path (no numbers on the end).
>
> The Content Indexing that Microsoft does, is a mondo bloat thing to do.
> It's orders of magnitude slower, and it takes all day to Content Index my
> "NAS collection".
>
> The Content Indexer is recommended to not be indexing more than 1 million files.
> That's what Microsoft specs as a practical limit. You can drive it harder
> than that, but expect some aspect to be slower.
>
> Summary: No one in their right mind uses the search box in File Explorer.
> How many times has it missed stuff ? You decide.
>
> But there are signs that maintainers still fiddle around with
> the implementation. In Win10 it uses Windows.edb "Jet Blue" database.
> In Win11 it uses Windows.db SQLite3 database. This makes no different
> at the user level (and isn't this why we write code???).
>
> I think if we had a Change Journal expert here, we could get an answer
> on how file moves are encoded, how many entries such an activity would
> span, and whether an architecture would allow optimization for it.
>
> It's the same when a naive person watches the miserably slow file deletion.
> The person would say "hey, why not stop the computer for a second,
> total up all the changes to the $MFT and just blast them in as a huge edit".
> and that causes a huge explanation of why we can't/won't be doing that.
> If that was even remotely possible, we'd have done it by now. Or at least,
> there would be a credible explanation of how we could do it.
>
> Paul
Paul, you're the idiot that claimed moving a file resulted in a
"deletefile" in the USN Journal...
...and you were spectacularly wrong.
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-10-06 21:47 -0400 |
| Message-ID | <10c1rg5$m0om$1@dont-email.me> |
| In reply to | #188032 |
On Mon, 10/6/2025 8:27 PM, Alan wrote:
>
> Paul, you're the idiot that claimed moving a file resulted in a "deletefile" in the USN Journal...
>
> ...and you were spectacularly wrong.
Here is some CoPilot feedback.
[Picture]
https://i.postimg.cc/J4qxv3Wn/Co-Pilot-Comment-On-USN.gif
[Picture]
https://i.postimg.cc/6pV8Yzs0/USN-move-testcase.gif
Paul
[toc] | [prev] | [next] | [standalone]
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Date | 2025-10-06 22:13 -0700 |
| Message-ID | <10c27in$o7v1$1@dont-email.me> |
| In reply to | #188033 |
On 2025-10-06 18:47, Paul wrote: > On Mon, 10/6/2025 8:27 PM, Alan wrote: > >> >> Paul, you're the idiot that claimed moving a file resulted in a "deletefile" in the USN Journal... >> >> ...and you were spectacularly wrong. > > Here is some CoPilot feedback. > > [Picture] > > https://i.postimg.cc/J4qxv3Wn/Co-Pilot-Comment-On-USN.gif > > [Picture] > > https://i.postimg.cc/6pV8Yzs0/USN-move-testcase.gif > > Paul And you're stupid enough to think Copilot is infallible. Sorry, but even Windows isn't stupid enough to record moving a file from one directory to another as a delete followed by a create. Moving a file from one directory to another on the same volume does NOT generate those entries. Period.
[toc] | [prev] | [next] | [standalone]
| From | Daniel70 <daniel47@nomail.afraid.org> |
|---|---|
| Date | 2025-10-08 22:01 +1100 |
| Message-ID | <10c5ga0$1hrih$1@dont-email.me> |
| In reply to | #188033 |
On 7/10/2025 12:47 pm, Paul wrote: > On Mon, 10/6/2025 8:27 PM, Alan wrote: > >> >> Paul, you're the idiot that claimed moving a file resulted in a "deletefile" in the USN Journal... >> >> ...and you were spectacularly wrong. > > Here is some CoPilot feedback. > > [Picture] > > https://i.postimg.cc/J4qxv3Wn/Co-Pilot-Comment-On-USN.gif Paul, in what you quote there from Co-pilot it seems you end up with a NEW file with a totally different File Name. Surely this can't be so .... or has Copilot just not completed the process?? > [Picture] > > https://i.postimg.cc/6pV8Yzs0/USN-move-testcase.gif > > Paul > -- Daniel70
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-10-08 10:45 -0400 |
| Message-ID | <10c5tdl$1lg3l$1@dont-email.me> |
| In reply to | #188088 |
On Wed, 10/8/2025 7:01 AM, Daniel70 wrote:
>
> Surely this can't be so .... or has Copilot just not completed the process??
You can make up cases and ask the AI for a result.
The idea of making my stupid cases, is just to get it
to dump the names of a representative set of possibilities.
To move a file can:
1) Require deleting it with a change journal event,
then create it with a second change journal event.
The AI tells us there is no single-event Move type for the job.
There is a tendency in computer systems designs to use
atomic events rather than "do fancy stuff". There is a lot of
fancy stuff we could do, which in the end we don't do.
2) Moves can be orchestrated by the Name Change set of change journal events.
Now, you have to prepare your set of file names, and then
figure out which of those cases apply. Take the actual move
command that demonstrated a problem and get the AI description
of how that would be coded.
The journal dumps I've tried, at some point the design must
have changed. I didn't make a fetish out of this. Like at
one time, you could see a write-file event dumped, for
every 256KB or so of data. I don't think that scheme was
in the latest try I made of a dump.
******************
CoPilot Question
In the NTFS change journal, has the design of the journal events been a
constant with time or did the change journal design or representation change over the years ?
CoPilot Answer
The NTFS Change Journal - also known as the USN Journal - has evolved over time,
though its core purpose has remained consistent: to efficiently track
changes to files and directories on an NTFS volume.
### 🕰️ Evolution of the Change Journal Design
Here’s how its design and representation have changed over the years:
#### 1. **Initial Introduction (Windows 2000 / NTFS 3.0)**
- The Change Journal was introduced with NTFS 3.0.
- It stored records in a metafile called `$Extend\$UsnJrnl`.
- Each record included:
- A 64-bit Update Sequence Number (USN)
- File reference number
- Reason flags (bitmask indicating the type of change)
- Timestamp
- File name
#### 2. **USN_RECORD Structure Versions**
- Over time, Microsoft introduced new versions of the `USN_RECORD` structure:
- **V2**: Used in early implementations (Windows 2000, XP, etc.)
- **V3 and V4**: Introduced in later versions of Windows to support new features and metadata
- These versions added fields like extended reason flags, source info, and more precise timestamps.
#### 3. **Bit Flags Expansion**
- The `Reason` field uses bit flags like `USN_REASON_DATA_OVERWRITE`, `USN_REASON_FILE_CREATE`, etc.
- New flags were added over time to reflect more granular changes (e.g., file renames, ACL changes).
#### 4. **Performance and Scalability Enhancements**
- As file systems grew to support millions of files, the journal’s internal mechanisms were optimized for speed and reduced overhead.
- Journals became more configurable (e.g., size limits, retention policies).
#### 5. **Integration with New Features**
- Windows features like **File History**, **Windows Search**, and **Backup utilities** began leveraging the Change Journal.
- This led to more robust APIs and better documentation for developers.
---
### 🔍 Summary
While the fundamental concept of logging file system changes has stayed the same,
the **structure**, **metadata**, and **integration points** of the NTFS Change Journal
have evolved to meet the demands of modern systems. It’s a great example of a
foundational technology quietly adapting behind the scenes.
Would you like to dive into the specifics of the USN_RECORD structure versions
or how backup tools use the journal today?
**********************************8
Paul
[toc] | [prev] | [next] | [standalone]
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Date | 2025-10-08 08:25 -0700 |
| Message-ID | <10c5vod$1m1kq$8@dont-email.me> |
| In reply to | #188096 |
On 2025-10-08 07:45, Paul wrote: > On Wed, 10/8/2025 7:01 AM, Daniel70 wrote: > >> >> Surely this can't be so .... or has Copilot just not completed the process?? > > You can make up cases and ask the AI for a result. And you can get garbage out. > > The idea of making my stupid cases, is just to get it > to dump the names of a representative set of possibilities. > > To move a file can: > > 1) Require deleting it with a change journal event, > then create it with a second change journal event. > The AI tells us there is no single-event Move type for the job. > There is a tendency in computer systems designs to use > atomic events rather than "do fancy stuff". There is a lot of > fancy stuff we could do, which in the end we don't do. > > 2) Moves can be orchestrated by the Name Change set of change journal events. > > Now, you have to prepare your set of file names, and then > figure out which of those cases apply. Take the actual move > command that demonstrated a problem and get the AI description > of how that would be coded. > > The journal dumps I've tried, at some point the design must > have changed. I didn't make a fetish out of this. Like at > one time, you could see a write-file event dumped, for > every 256KB or so of data. I don't think that scheme was > in the latest try I made of a dump. > > ****************** > > CoPilot Question > > In the NTFS change journal, has the design of the journal events been a > constant with time or did the change journal design or representation change over the years ? > > CoPilot Answer > > The NTFS Change Journal - also known as the USN Journal - has evolved over time, > though its core purpose has remained consistent: to efficiently track > changes to files and directories on an NTFS volume. > > ### 🕰️ Evolution of the Change Journal Design > > Here’s how its design and representation have changed over the years: > > #### 1. **Initial Introduction (Windows 2000 / NTFS 3.0)** > - The Change Journal was introduced with NTFS 3.0. > - It stored records in a metafile called `$Extend\$UsnJrnl`. > - Each record included: > - A 64-bit Update Sequence Number (USN) > - File reference number > - Reason flags (bitmask indicating the type of change) > - Timestamp > - File name > > #### 2. **USN_RECORD Structure Versions** > - Over time, Microsoft introduced new versions of the `USN_RECORD` structure: > - **V2**: Used in early implementations (Windows 2000, XP, etc.) > - **V3 and V4**: Introduced in later versions of Windows to support new features and metadata > - These versions added fields like extended reason flags, source info, and more precise timestamps. > > #### 3. **Bit Flags Expansion** > - The `Reason` field uses bit flags like `USN_REASON_DATA_OVERWRITE`, `USN_REASON_FILE_CREATE`, etc. > - New flags were added over time to reflect more granular changes (e.g., file renames, ACL changes). > > #### 4. **Performance and Scalability Enhancements** > - As file systems grew to support millions of files, the journal’s internal mechanisms were optimized for speed and reduced overhead. > - Journals became more configurable (e.g., size limits, retention policies). > > #### 5. **Integration with New Features** > - Windows features like **File History**, **Windows Search**, and **Backup utilities** began leveraging the Change Journal. > - This led to more robust APIs and better documentation for developers. > --- > ### 🔍 Summary > > While the fundamental concept of logging file system changes has stayed the same, > the **structure**, **metadata**, and **integration points** of the NTFS Change Journal > have evolved to meet the demands of modern systems. It’s a great example of a > foundational technology quietly adapting behind the scenes. > > Would you like to dive into the specifics of the USN_RECORD structure versions > or how backup tools use the journal today? > **********************************8 > > Paul
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | alt.comp.os.windows-10
csiph-web