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 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Date | 2025-10-08 08:20 -0700 |
| Message-ID | <10c5vfb$1m1kq$2@dont-email.me> |
| In reply to | #188076 |
On 2025-10-08 02:23, Daniel70 wrote: > On 7/10/2025 3:33 am, Alan wrote: >> On 2025-10-06 09:28, MikeS wrote: >>> On 06/10/2025 10:54, Daniel70 wrote: >>>> On 6/10/2025 7:56 pm, MikeS wrote: >>>>> On 06/10/2025 09:23, Daniel70 wrote: >>>>>> On 6/10/2025 3:16 pm, Alan wrote: >>>>>>> On 2025-10-05 19:46, Lars Poulsen wrote: >>>>>>>> Alan <nuh-uh@nope.com> wrote: Alan>>> If I do a similar >>>>>>>> thing on macOS, it's done almost before the files Alan>>> >>>>>>>> have finished the move >>>>>>>> >>>>>>>>> On 2025-10-01 13:19, Carlos E.R. wrote: >>>>>>>> Carlos>> Not if it does content indexing. >>>>>>>> >>>>>>>> Alan> If a file has already BEEN indexed for its >>>>>>>> content... Alan> ...why would simply moving it to a new >>>>>>>> location require it to be re-read? Alan> Did its content >>>>>>>> magically change just because you moved it? Alan> No. >>>>>>>> >>>>>>>> This is the difference between indexing on demand versus >>>>>>>> CONTINUOUSLY MAINTAINING an index. >>>>>>> >>>>>>> I'm sorry, but you're wrong. >>>>>>> >>>>>>> You index a file so that you can find it based on metadata >>>>>>> and content. >>>>>>> >>>>>>> When a search happens, the INDEX gets searched the location >>>>>>> of the file is returned. >>>>>>> >>>>>>> The location of the file is ONE single piece of information >>>>>>> in the indexing system about the file. >>>>>>> >>>>>>> Move the file and all you need to do is update that one >>>>>>> piece of information. >>>>>>> >>>>>>> Nothing else has changed: not it's name, not it's date >>>>>>> modified or last opened, not it's content. >>>>>>> >>>>>>> So there is no need to re-read the file. >>>>>> >>>>>> How is your system supposed to know that the contents of the >>>>>> "new" "moved" file is *EXACTLY* the same as the original file >>>>>> (never had an individual Byte/Bit of RAM die on you??) .... >>>>>> unless it still HAS the "original" file to compare the new >>>>>> file too?? >>>>> >>>>> As it happens I have never *noticed* an individual Byte/Bit of >>>>> RAM die on me. If it did that would have zero effect on the >>>>> index data needed to search for the file. >>>> >>>> Sure .... but it would mean that the 'moved' file *IS* different >>>> to the original File. >>> >>> No .... it would mean that the 'moved' file *IS* corrupted. > > AH!! So MikeS doesn't consider a moved but corrupted file is different > to the original file. Good to know!! I file IS NEVER CORRUPTED by a "move" from one place to another on a single volume. NEVER!!! Because the data is NOT BEING REWRITTEN.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-10-06 14:22 +0200 |
| Message-ID | <ltocrlxipn.ln2@Telcontar.valinor> |
| In reply to | #187989 |
On 2025-10-06 10:23, Daniel70 wrote: > On 6/10/2025 3:16 pm, Alan wrote: >> On 2025-10-05 19:46, Lars Poulsen wrote: >>> Alan <nuh-uh@nope.com> wrote: >>> Alan>>> If I do a similar thing on macOS, it's done almost before the >>> files >>> Alan>>> have finished the move >>> >>>> On 2025-10-01 13:19, Carlos E.R. wrote: >>> Carlos>> Not if it does content indexing. >>> >>> Alan> If a file has already BEEN indexed for its content... >>> Alan> ...why would simply moving it to a new location require it to >>> be re-read? >>> Alan> Did its content magically change just because you moved it? >>> Alan> No. >>> >>> This is the difference between indexing on demand versus CONTINUOUSLY >>> MAINTAINING an index. >> >> I'm sorry, but you're wrong. >> >> You index a file so that you can find it based on metadata and content. >> >> When a search happens, the INDEX gets searched the location of the >> file is returned. >> >> The location of the file is ONE single piece of information in the >> indexing system about the file. >> >> Move the file and all you need to do is update that one piece of >> information. >> >> Nothing else has changed: not it's name, not it's date modified or >> last opened, not it's content. >> >> So there is no need to re-read the file. > > How is your system supposed to know that the contents of the "new" > "moved" file is *EXACTLY* the same as the original file (never had an > individual Byte/Bit of RAM die on you??) .... unless it still HAS the > "original" file to compare the new file too?? Two possibilities. a) There is a service, or daemon, that is tracking all move operations (it must be connected to the system libraries that do the moves). Ie, the kernel is designed to track moves and inform some higher level layer about this. Thus the indexer is told that a file moved location. b) The indexer does some fast checking of the file (name, attributes, etc) and if it is the same, it assumes the file has moved. Maybe verification is delayed. -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Date | 2025-10-06 09:00 -0700 |
| Message-ID | <10c0p25$d6mu$3@dont-email.me> |
| In reply to | #187999 |
On 2025-10-06 05:22, Carlos E.R. wrote: > On 2025-10-06 10:23, Daniel70 wrote: >> On 6/10/2025 3:16 pm, Alan wrote: >>> On 2025-10-05 19:46, Lars Poulsen wrote: >>>> Alan <nuh-uh@nope.com> wrote: >>>> Alan>>> If I do a similar thing on macOS, it's done almost before >>>> the files >>>> Alan>>> have finished the move >>>> >>>>> On 2025-10-01 13:19, Carlos E.R. wrote: >>>> Carlos>> Not if it does content indexing. >>>> >>>> Alan> If a file has already BEEN indexed for its content... >>>> Alan> ...why would simply moving it to a new location require it to >>>> be re-read? >>>> Alan> Did its content magically change just because you moved it? >>>> Alan> No. >>>> >>>> This is the difference between indexing on demand versus CONTINUOUSLY >>>> MAINTAINING an index. >>> >>> I'm sorry, but you're wrong. >>> >>> You index a file so that you can find it based on metadata and content. >>> >>> When a search happens, the INDEX gets searched the location of the >>> file is returned. >>> >>> The location of the file is ONE single piece of information in the >>> indexing system about the file. >>> >>> Move the file and all you need to do is update that one piece of >>> information. >>> >>> Nothing else has changed: not it's name, not it's date modified or >>> last opened, not it's content. >>> >>> So there is no need to re-read the file. >> >> How is your system supposed to know that the contents of the "new" >> "moved" file is *EXACTLY* the same as the original file (never had an >> individual Byte/Bit of RAM die on you??) .... unless it still HAS the >> "original" file to compare the new file too?? > > Two possibilities. > > a) There is a service, or daemon, that is tracking all move > operations (it must be connected to the system libraries that do the > moves). Ie, the kernel is designed to track moves and inform some higher > level layer about this. Thus the indexer is told that a file moved > location. Duh. > > b) The indexer does some fast checking of the file (name, attributes, > etc) and if it is the same, it assumes the file has moved. Maybe > verification is delayed. > >
[toc] | [prev] | [next] | [standalone]
| From | Daniel70 <daniel47@nomail.afraid.org> |
|---|---|
| Date | 2025-10-08 20:30 +1100 |
| Message-ID | <10c5avf$1gd4v$1@dont-email.me> |
| In reply to | #187999 |
On 6/10/2025 11:22 pm, Carlos E.R. wrote: > On 2025-10-06 10:23, Daniel70 wrote: >> On 6/10/2025 3:16 pm, Alan wrote: >>> On 2025-10-05 19:46, Lars Poulsen wrote: >>>> Alan <nuh-uh@nope.com> wrote: >>>> Alan>>> If I do a similar thing on macOS, it's done almost before >>>> the files >>>> Alan>>> have finished the move >>>> >>>>> On 2025-10-01 13:19, Carlos E.R. wrote: >>>> Carlos>> Not if it does content indexing. >>>> >>>> Alan> If a file has already BEEN indexed for its content... >>>> Alan> ...why would simply moving it to a new location require it to >>>> be re-read? >>>> Alan> Did its content magically change just because you moved it? >>>> Alan> No. >>>> >>>> This is the difference between indexing on demand versus CONTINUOUSLY >>>> MAINTAINING an index. >>> >>> I'm sorry, but you're wrong. >>> >>> You index a file so that you can find it based on metadata and content. >>> >>> When a search happens, the INDEX gets searched the location of the >>> file is returned. >>> >>> The location of the file is ONE single piece of information in the >>> indexing system about the file. >>> >>> Move the file and all you need to do is update that one piece of >>> information. >>> >>> Nothing else has changed: not it's name, not it's date modified or >>> last opened, not it's content. >>> >>> So there is no need to re-read the file. >> >> How is your system supposed to know that the contents of the "new" >> "moved" file is *EXACTLY* the same as the original file (never had an >> individual Byte/Bit of RAM die on you??) .... unless it still HAS the >> "original" file to compare the new file too?? > > Two possibilities. > > a) There is a service, or daemon, that is tracking all move > operations (it must be connected to the system libraries that do the > moves). Ie, the kernel is designed to track moves and inform some higher > level layer about this. Thus the indexer is told that a file moved > location. > > b) The indexer does some fast checking of the file (name, attributes, > etc) and if it is the same, it assumes the file has moved. Maybe > verification is delayed. > So are you, Carlos, suggesting that, at the time of the move/copy, the OS does not check that what ends up at the new/final location is the same as what was in the old/original location?? If that *IS* the case, I hope no-one EVER does a Defrag!! EVER!! -- Daniel70
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-10-08 11:48 +0200 |
| Message-ID | <3kohrlxffi.ln2@Telcontar.valinor> |
| In reply to | #188078 |
On 2025-10-08 11:30, Daniel70 wrote: > On 6/10/2025 11:22 pm, Carlos E.R. wrote: >> On 2025-10-06 10:23, Daniel70 wrote: >>> On 6/10/2025 3:16 pm, Alan wrote: >>>> On 2025-10-05 19:46, Lars Poulsen wrote: >>>>> Alan <nuh-uh@nope.com> wrote: >>>>> Alan>>> If I do a similar thing on macOS, it's done almost before >>>>> the files >>>>> Alan>>> have finished the move >>>>> >>>>>> On 2025-10-01 13:19, Carlos E.R. wrote: >>>>> Carlos>> Not if it does content indexing. >>>>> >>>>> Alan> If a file has already BEEN indexed for its content... >>>>> Alan> ...why would simply moving it to a new location require it to >>>>> be re-read? >>>>> Alan> Did its content magically change just because you moved it? >>>>> Alan> No. >>>>> >>>>> This is the difference between indexing on demand versus CONTINUOUSLY >>>>> MAINTAINING an index. >>>> >>>> I'm sorry, but you're wrong. >>>> >>>> You index a file so that you can find it based on metadata and content. >>>> >>>> When a search happens, the INDEX gets searched the location of the >>>> file is returned. >>>> >>>> The location of the file is ONE single piece of information in the >>>> indexing system about the file. >>>> >>>> Move the file and all you need to do is update that one piece of >>>> information. >>>> >>>> Nothing else has changed: not it's name, not it's date modified or >>>> last opened, not it's content. >>>> >>>> So there is no need to re-read the file. >>> >>> How is your system supposed to know that the contents of the "new" >>> "moved" file is *EXACTLY* the same as the original file (never had an >>> individual Byte/Bit of RAM die on you??) .... unless it still HAS the >>> "original" file to compare the new file too?? >> >> Two possibilities. >> >> a) There is a service, or daemon, that is tracking all move >> operations (it must be connected to the system libraries that do the >> moves). Ie, the kernel is designed to track moves and inform some >> higher level layer about this. Thus the indexer is told that a file >> moved location. >> >> b) The indexer does some fast checking of the file (name, >> attributes, etc) and if it is the same, it assumes the file has moved. >> Maybe verification is delayed. >> > So are you, Carlos, suggesting that, at the time of the move/copy, the > OS does not check that what ends up at the new/final location is the > same as what was in the old/original location?? If it is an move via hardlink operation, then as the data sectors are not touched, only the metadata, the data is guaranteed to be the same. If it is copy-and-delete operation, the system does not do an automated check that what is actually written is the same data. However, the userland program doing the operation can do a verify before delete. > > If that *IS* the case, I hope no-one EVER does a Defrag!! EVER!! Not related, either. The application doing the defrag can do a verify. In Linux, there are filesystems that store a checksum of files in the metadata, so that integrity can be verified. It is not the default. -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | "J. P. Gilliver" <G6JPG@255soft.uk> |
|---|---|
| Date | 2025-10-08 11:25 +0100 |
| Message-ID | <10c5e7c$12qst$9@dont-email.me> |
| In reply to | #188081 |
On 2025/10/8 10:48:19, Carlos E.R. wrote: > On 2025-10-08 11:30, Daniel70 wrote: [] >> So are you, Carlos, suggesting that, at the time of the move/copy, the >> OS does not check that what ends up at the new/final location is the >> same as what was in the old/original location?? > > If it is an move via hardlink operation, then as the data sectors are > not touched, only the metadata, the data is guaranteed to be the same. (Hmm, arguably that's not a move, though it looks like one to the user - a "move" to another place on the same partition usually only involves changing pointers.)> > If it is copy-and-delete operation, the system does not do an automated > check that what is actually written is the same data. Indeed. The _checksums_ (or more complex equivalents) may well be recalculated (possibly at the hardware level).> > However, the userland program doing the operation can do a verify before > delete. Indeed. A lot of copy/move commands have a verify _option_; I don't know if any have it on by default.> >> >> If that *IS* the case, I hope no-one EVER does a Defrag!! EVER!! > > Not related, either. The application doing the defrag can do a verify. > Well, it _is_ related: a defrag _is_ a copy-and-delete (usually many of them). How many defrags do verify by default, I do not know.> > In Linux, there are filesystems that store a checksum of files in the > metadata, so that integrity can be verified. It is not the default. > A lot of (all modern, even floppy?) systems - hard disc drives, probably SSDs - do that at a low level anyway, as their error-correction mechanism.> -- J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf "If god doesn't like the way I live, Let him tell me, not you." - unknown
[toc] | [prev] | [next] | [standalone]
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Date | 2025-10-08 08:22 -0700 |
| Message-ID | <10c5vj8$1m1kq$5@dont-email.me> |
| In reply to | #188085 |
On 2025-10-08 03:25, J. P. Gilliver wrote: > On 2025/10/8 10:48:19, Carlos E.R. wrote: >> On 2025-10-08 11:30, Daniel70 wrote: > > [] > > >>> So are you, Carlos, suggesting that, at the time of the move/copy, the >>> OS does not check that what ends up at the new/final location is the >>> same as what was in the old/original location?? >> >> If it is an move via hardlink operation, then as the data sectors are >> not touched, only the metadata, the data is guaranteed to be the same. > > (Hmm, arguably that's not a move, though it looks like one to the user - > a "move" to another place on the same partition usually only involves > changing pointers.)> Exactly. >> If it is copy-and-delete operation, the system does not do an automated >> check that what is actually written is the same data. > > Indeed. The _checksums_ (or more complex equivalents) may well be > recalculated (possibly at the hardware level).> >> However, the userland program doing the operation can do a verify before >> delete. > > Indeed. A lot of copy/move commands have a verify _option_; I don't know > if any have it on by default.> >>> >>> If that *IS* the case, I hope no-one EVER does a Defrag!! EVER!! >> >> Not related, either. The application doing the defrag can do a verify. >> > Well, it _is_ related: a defrag _is_ a copy-and-delete (usually many of > them). How many defrags do verify by default, I do not know.> >> In Linux, there are filesystems that store a checksum of files in the >> metadata, so that integrity can be verified. It is not the default. >> > A lot of (all modern, even floppy?) systems - hard disc drives, probably > SSDs - do that at a low level anyway, as their error-correction mechanism.> > > >
[toc] | [prev] | [next] | [standalone]
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Date | 2025-10-08 08:21 -0700 |
| Message-ID | <10c5vi5$1m1kq$4@dont-email.me> |
| In reply to | #188081 |
On 2025-10-08 02:48, Carlos E.R. wrote: > On 2025-10-08 11:30, Daniel70 wrote: >> On 6/10/2025 11:22 pm, Carlos E.R. wrote: >>> On 2025-10-06 10:23, Daniel70 wrote: >>>> On 6/10/2025 3:16 pm, Alan wrote: >>>>> On 2025-10-05 19:46, Lars Poulsen wrote: >>>>>> Alan <nuh-uh@nope.com> wrote: >>>>>> Alan>>> If I do a similar thing on macOS, it's done almost before >>>>>> the files >>>>>> Alan>>> have finished the move >>>>>> >>>>>>> On 2025-10-01 13:19, Carlos E.R. wrote: >>>>>> Carlos>> Not if it does content indexing. >>>>>> >>>>>> Alan> If a file has already BEEN indexed for its content... >>>>>> Alan> ...why would simply moving it to a new location require it >>>>>> to be re-read? >>>>>> Alan> Did its content magically change just because you moved it? >>>>>> Alan> No. >>>>>> >>>>>> This is the difference between indexing on demand versus CONTINUOUSLY >>>>>> MAINTAINING an index. >>>>> >>>>> I'm sorry, but you're wrong. >>>>> >>>>> You index a file so that you can find it based on metadata and >>>>> content. >>>>> >>>>> When a search happens, the INDEX gets searched the location of the >>>>> file is returned. >>>>> >>>>> The location of the file is ONE single piece of information in the >>>>> indexing system about the file. >>>>> >>>>> Move the file and all you need to do is update that one piece of >>>>> information. >>>>> >>>>> Nothing else has changed: not it's name, not it's date modified or >>>>> last opened, not it's content. >>>>> >>>>> So there is no need to re-read the file. >>>> >>>> How is your system supposed to know that the contents of the "new" >>>> "moved" file is *EXACTLY* the same as the original file (never had >>>> an individual Byte/Bit of RAM die on you??) .... unless it still HAS >>>> the "original" file to compare the new file too?? >>> >>> Two possibilities. >>> >>> a) There is a service, or daemon, that is tracking all move >>> operations (it must be connected to the system libraries that do the >>> moves). Ie, the kernel is designed to track moves and inform some >>> higher level layer about this. Thus the indexer is told that a file >>> moved location. >>> >>> b) The indexer does some fast checking of the file (name, >>> attributes, etc) and if it is the same, it assumes the file has >>> moved. Maybe verification is delayed. >>> >> So are you, Carlos, suggesting that, at the time of the move/copy, the >> OS does not check that what ends up at the new/final location is the >> same as what was in the old/original location?? > > If it is an move via hardlink operation, then as the data sectors are > not touched, only the metadata, the data is guaranteed to be the same. > > If it is copy-and-delete operation, the system does not do an automated > check that what is actually written is the same data. > > However, the userland program doing the operation can do a verify before > delete. No OS does a "copy-and-delete" for a move within a single volume. > >> >> If that *IS* the case, I hope no-one EVER does a Defrag!! EVER!! > > Not related, either. The application doing the defrag can do a verify. > > > In Linux, there are filesystems that store a checksum of files in the > metadata, so that integrity can be verified. It is not the default. > >
[toc] | [prev] | [next] | [standalone]
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Date | 2025-10-08 08:20 -0700 |
| Message-ID | <10c5vgg$1m1kq$3@dont-email.me> |
| In reply to | #188078 |
On 2025-10-08 02:30, Daniel70 wrote:
> On 6/10/2025 11:22 pm, Carlos E.R. wrote:
>> On 2025-10-06 10:23, Daniel70 wrote:
>>> On 6/10/2025 3:16 pm, Alan wrote:
>>>> On 2025-10-05 19:46, Lars Poulsen wrote:
>>>>> Alan <nuh-uh@nope.com> wrote:
>>>>> Alan>>> If I do a similar thing on macOS, it's done almost before
>>>>> the files
>>>>> Alan>>> have finished the move
>>>>>
>>>>>> On 2025-10-01 13:19, Carlos E.R. wrote:
>>>>> Carlos>> Not if it does content indexing.
>>>>>
>>>>> Alan> If a file has already BEEN indexed for its content...
>>>>> Alan> ...why would simply moving it to a new location require it to
>>>>> be re-read?
>>>>> Alan> Did its content magically change just because you moved it?
>>>>> Alan> No.
>>>>>
>>>>> This is the difference between indexing on demand versus CONTINUOUSLY
>>>>> MAINTAINING an index.
>>>>
>>>> I'm sorry, but you're wrong.
>>>>
>>>> You index a file so that you can find it based on metadata and content.
>>>>
>>>> When a search happens, the INDEX gets searched the location of the
>>>> file is returned.
>>>>
>>>> The location of the file is ONE single piece of information in the
>>>> indexing system about the file.
>>>>
>>>> Move the file and all you need to do is update that one piece of
>>>> information.
>>>>
>>>> Nothing else has changed: not it's name, not it's date modified or
>>>> last opened, not it's content.
>>>>
>>>> So there is no need to re-read the file.
>>>
>>> How is your system supposed to know that the contents of the "new"
>>> "moved" file is *EXACTLY* the same as the original file (never had an
>>> individual Byte/Bit of RAM die on you??) .... unless it still HAS the
>>> "original" file to compare the new file too??
>>
>> Two possibilities.
>>
>> a) There is a service, or daemon, that is tracking all move
>> operations (it must be connected to the system libraries that do the
>> moves). Ie, the kernel is designed to track moves and inform some
>> higher level layer about this. Thus the indexer is told that a file
>> moved location.
>>
>> b) The indexer does some fast checking of the file (name,
>> attributes, etc) and if it is the same, it assumes the file has moved.
>> Maybe verification is delayed.
>>
> So are you, Carlos, suggesting that, at the time of the move/copy, the
> OS does not check that what ends up at the new/final location is the
> same as what was in the old/original location??
>
> If that *IS* the case, I hope no-one EVER does a Defrag!! EVER!!
I will say this over and over until the ignorant get the message:
When you "move" a file from one directory to another directory on the
same volume there is no second file ("ORIGINAL" vs "RELOCATED")
The file's data NEVER MOVES.
A "move" as described is literally NO DIFFERENT than just renaming the
file, so there is no need to check that something has been changed.
[toc] | [prev] | [next] | [standalone]
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Date | 2025-10-06 08:58 -0700 |
| Message-ID | <10c0ouj$d6mu$1@dont-email.me> |
| In reply to | #187989 |
On 2025-10-06 01:23, Daniel70 wrote: > On 6/10/2025 3:16 pm, Alan wrote: >> On 2025-10-05 19:46, Lars Poulsen wrote: >>> Alan <nuh-uh@nope.com> wrote: >>> Alan>>> If I do a similar thing on macOS, it's done almost before the >>> files >>> Alan>>> have finished the move >>> >>>> On 2025-10-01 13:19, Carlos E.R. wrote: >>> Carlos>> Not if it does content indexing. >>> >>> Alan> If a file has already BEEN indexed for its content... >>> Alan> ...why would simply moving it to a new location require it to >>> be re-read? >>> Alan> Did its content magically change just because you moved it? >>> Alan> No. >>> >>> This is the difference between indexing on demand versus CONTINUOUSLY >>> MAINTAINING an index. >> >> I'm sorry, but you're wrong. >> >> You index a file so that you can find it based on metadata and content. >> >> When a search happens, the INDEX gets searched the location of the >> file is returned. >> >> The location of the file is ONE single piece of information in the >> indexing system about the file. >> >> Move the file and all you need to do is update that one piece of >> information. >> >> Nothing else has changed: not it's name, not it's date modified or >> last opened, not it's content. >> >> So there is no need to re-read the file. > > How is your system supposed to know that the contents of the "new" > "moved" file is *EXACTLY* the same as the original file (never had an > individual Byte/Bit of RAM die on you??) .... unless it still HAS the > "original" file to compare the new file too?? Oh dear GOD! You cannot be this ignorant. When you "move" a file from one directory to another on a partition, the actual data of the file IS NOT TOUCHED. The individual bits of the file stay in exactly the same place. All that's changed is the file system's record of which directory the file should be displayed as being in. Do you know what a "hard link" is?
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-10-06 22:44 +0200 |
| Message-ID | <oamdrlxueb.ln2@Telcontar.valinor> |
| In reply to | #188004 |
On 2025-10-06 17:58, Alan wrote: > On 2025-10-06 01:23, Daniel70 wrote: >> On 6/10/2025 3:16 pm, Alan wrote: >>> On 2025-10-05 19:46, Lars Poulsen wrote: >>>> Alan <nuh-uh@nope.com> wrote: >>>> Alan>>> If I do a similar thing on macOS, it's done almost before >>>> the files >>>> Alan>>> have finished the move >>>> >>>>> On 2025-10-01 13:19, Carlos E.R. wrote: >>>> Carlos>> Not if it does content indexing. >>>> >>>> Alan> If a file has already BEEN indexed for its content... >>>> Alan> ...why would simply moving it to a new location require it to >>>> be re-read? >>>> Alan> Did its content magically change just because you moved it? >>>> Alan> No. >>>> >>>> This is the difference between indexing on demand versus CONTINUOUSLY >>>> MAINTAINING an index. >>> >>> I'm sorry, but you're wrong. >>> >>> You index a file so that you can find it based on metadata and content. >>> >>> When a search happens, the INDEX gets searched the location of the >>> file is returned. >>> >>> The location of the file is ONE single piece of information in the >>> indexing system about the file. >>> >>> Move the file and all you need to do is update that one piece of >>> information. >>> >>> Nothing else has changed: not it's name, not it's date modified or >>> last opened, not it's content. >>> >>> So there is no need to re-read the file. >> >> How is your system supposed to know that the contents of the "new" >> "moved" file is *EXACTLY* the same as the original file (never had an >> individual Byte/Bit of RAM die on you??) .... unless it still HAS the >> "original" file to compare the new file too?? > > Oh dear GOD! > > You cannot be this ignorant. > > When you "move" a file from one directory to another on a partition, the > actual data of the file IS NOT TOUCHED. > > The individual bits of the file stay in exactly the same place. > > All that's changed is the file system's record of which directory the > file should be displayed as being in. > > Do you know what a "hard link" is? And how does the indexer know that this has happened? Oh, Windows supports hardlinks only on NTFS. Not on FAT or exFAT or ReFS. -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Date | 2025-10-06 13:56 -0700 |
| Message-ID | <10c1aee$h6gk$2@dont-email.me> |
| In reply to | #188022 |
On 2025-10-06 13:44, Carlos E.R. wrote: > On 2025-10-06 17:58, Alan wrote: >> On 2025-10-06 01:23, Daniel70 wrote: >>> On 6/10/2025 3:16 pm, Alan wrote: >>>> On 2025-10-05 19:46, Lars Poulsen wrote: >>>>> Alan <nuh-uh@nope.com> wrote: >>>>> Alan>>> If I do a similar thing on macOS, it's done almost before >>>>> the files >>>>> Alan>>> have finished the move >>>>> >>>>>> On 2025-10-01 13:19, Carlos E.R. wrote: >>>>> Carlos>> Not if it does content indexing. >>>>> >>>>> Alan> If a file has already BEEN indexed for its content... >>>>> Alan> ...why would simply moving it to a new location require it to >>>>> be re-read? >>>>> Alan> Did its content magically change just because you moved it? >>>>> Alan> No. >>>>> >>>>> This is the difference between indexing on demand versus CONTINUOUSLY >>>>> MAINTAINING an index. >>>> >>>> I'm sorry, but you're wrong. >>>> >>>> You index a file so that you can find it based on metadata and content. >>>> >>>> When a search happens, the INDEX gets searched the location of the >>>> file is returned. >>>> >>>> The location of the file is ONE single piece of information in the >>>> indexing system about the file. >>>> >>>> Move the file and all you need to do is update that one piece of >>>> information. >>>> >>>> Nothing else has changed: not it's name, not it's date modified or >>>> last opened, not it's content. >>>> >>>> So there is no need to re-read the file. >>> >>> How is your system supposed to know that the contents of the "new" >>> "moved" file is *EXACTLY* the same as the original file (never had an >>> individual Byte/Bit of RAM die on you??) .... unless it still HAS the >>> "original" file to compare the new file too?? >> >> Oh dear GOD! >> >> You cannot be this ignorant. >> >> When you "move" a file from one directory to another on a partition, >> the actual data of the file IS NOT TOUCHED. >> >> The individual bits of the file stay in exactly the same place. >> >> All that's changed is the file system's record of which directory the >> file should be displayed as being in. >> >> Do you know what a "hard link" is? > > And how does the indexer know that this has happened? How does the indexer know ANYTHING has happened? How about, it checks the file system journal. A "new file" entry: index that file. A "file modified" entriy: index that file. A "file moved" entry: modify the index to show the new location. > > Oh, Windows supports hardlinks only on NTFS. Not on FAT or exFAT or ReFS. Yeah... ...I know.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-10-06 23:22 +0200 |
| Message-ID | <6iodrlxelg.ln2@Telcontar.valinor> |
| In reply to | #188025 |
On 2025-10-06 22:56, Alan wrote: > On 2025-10-06 13:44, Carlos E.R. wrote: >> On 2025-10-06 17:58, Alan wrote: >>> On 2025-10-06 01:23, Daniel70 wrote: >>>> On 6/10/2025 3:16 pm, Alan wrote: >>>>> On 2025-10-05 19:46, Lars Poulsen wrote: >>>>>> Alan <nuh-uh@nope.com> wrote: >>>>>> Alan>>> If I do a similar thing on macOS, it's done almost before >>>>>> the files >>>>>> Alan>>> have finished the move >>>>>> >>>>>>> On 2025-10-01 13:19, Carlos E.R. wrote: >>>>>> Carlos>> Not if it does content indexing. >>>>>> >>>>>> Alan> If a file has already BEEN indexed for its content... >>>>>> Alan> ...why would simply moving it to a new location require it >>>>>> to be re-read? >>>>>> Alan> Did its content magically change just because you moved it? >>>>>> Alan> No. >>>>>> >>>>>> This is the difference between indexing on demand versus CONTINUOUSLY >>>>>> MAINTAINING an index. >>>>> >>>>> I'm sorry, but you're wrong. >>>>> >>>>> You index a file so that you can find it based on metadata and >>>>> content. >>>>> >>>>> When a search happens, the INDEX gets searched the location of the >>>>> file is returned. >>>>> >>>>> The location of the file is ONE single piece of information in the >>>>> indexing system about the file. >>>>> >>>>> Move the file and all you need to do is update that one piece of >>>>> information. >>>>> >>>>> Nothing else has changed: not it's name, not it's date modified or >>>>> last opened, not it's content. >>>>> >>>>> So there is no need to re-read the file. >>>> >>>> How is your system supposed to know that the contents of the "new" >>>> "moved" file is *EXACTLY* the same as the original file (never had >>>> an individual Byte/Bit of RAM die on you??) .... unless it still HAS >>>> the "original" file to compare the new file too?? >>> >>> Oh dear GOD! >>> >>> You cannot be this ignorant. >>> >>> When you "move" a file from one directory to another on a partition, >>> the actual data of the file IS NOT TOUCHED. >>> >>> The individual bits of the file stay in exactly the same place. >>> >>> All that's changed is the file system's record of which directory the >>> file should be displayed as being in. >>> >>> Do you know what a "hard link" is? >> >> And how does the indexer know that this has happened? > > How does the indexer know ANYTHING has happened? > > How about, it checks the file system journal. Can it? I have my doubts. In Linux, it is in kernelspace. I don't know if it can be queried. > > A "new file" entry: index that file. > > A "file modified" entriy: index that file. > > A "file moved" entry: modify the index to show the new location. > > >> >> Oh, Windows supports hardlinks only on NTFS. Not on FAT or exFAT or ReFS. > Yeah... ...I know. Well, this thread is posted on two windows groups. -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Date | 2025-10-06 16:51 -0700 |
| Message-ID | <10c1klq$kair$1@dont-email.me> |
| In reply to | #188027 |
On 2025-10-06 14:22, Carlos E.R. wrote: > On 2025-10-06 22:56, Alan wrote: >> On 2025-10-06 13:44, Carlos E.R. wrote: >>> On 2025-10-06 17:58, Alan wrote: >>>> On 2025-10-06 01:23, Daniel70 wrote: >>>>> On 6/10/2025 3:16 pm, Alan wrote: >>>>>> On 2025-10-05 19:46, Lars Poulsen wrote: >>>>>>> Alan <nuh-uh@nope.com> wrote: >>>>>>> Alan>>> If I do a similar thing on macOS, it's done almost before >>>>>>> the files >>>>>>> Alan>>> have finished the move >>>>>>> >>>>>>>> On 2025-10-01 13:19, Carlos E.R. wrote: >>>>>>> Carlos>> Not if it does content indexing. >>>>>>> >>>>>>> Alan> If a file has already BEEN indexed for its content... >>>>>>> Alan> ...why would simply moving it to a new location require it >>>>>>> to be re-read? >>>>>>> Alan> Did its content magically change just because you moved it? >>>>>>> Alan> No. >>>>>>> >>>>>>> This is the difference between indexing on demand versus >>>>>>> CONTINUOUSLY >>>>>>> MAINTAINING an index. >>>>>> >>>>>> I'm sorry, but you're wrong. >>>>>> >>>>>> You index a file so that you can find it based on metadata and >>>>>> content. >>>>>> >>>>>> When a search happens, the INDEX gets searched the location of the >>>>>> file is returned. >>>>>> >>>>>> The location of the file is ONE single piece of information in the >>>>>> indexing system about the file. >>>>>> >>>>>> Move the file and all you need to do is update that one piece of >>>>>> information. >>>>>> >>>>>> Nothing else has changed: not it's name, not it's date modified or >>>>>> last opened, not it's content. >>>>>> >>>>>> So there is no need to re-read the file. >>>>> >>>>> How is your system supposed to know that the contents of the "new" >>>>> "moved" file is *EXACTLY* the same as the original file (never had >>>>> an individual Byte/Bit of RAM die on you??) .... unless it still >>>>> HAS the "original" file to compare the new file too?? >>>> >>>> Oh dear GOD! >>>> >>>> You cannot be this ignorant. >>>> >>>> When you "move" a file from one directory to another on a partition, >>>> the actual data of the file IS NOT TOUCHED. >>>> >>>> The individual bits of the file stay in exactly the same place. >>>> >>>> All that's changed is the file system's record of which directory >>>> the file should be displayed as being in. >>>> >>>> Do you know what a "hard link" is? >>> >>> And how does the indexer know that this has happened? >> >> How does the indexer know ANYTHING has happened? >> >> How about, it checks the file system journal. > > Can it? > > I have my doubts. In Linux, it is in kernelspace. I don't know if it can > be queried. Are you serious? Why in the HELL would you do that? > >> >> A "new file" entry: index that file. >> >> A "file modified" entriy: index that file. >> >> A "file moved" entry: modify the index to show the new location. >> >> >>> >>> Oh, Windows supports hardlinks only on NTFS. Not on FAT or exFAT or >>> ReFS. >> Yeah... ...I know. > > Well, this thread is posted on two windows groups. Because Windows absolutely SUCKS at this.
[toc] | [prev] | [next] | [standalone]
| From | Daniel70 <daniel47@nomail.afraid.org> |
|---|---|
| Date | 2025-10-08 20:35 +1100 |
| Message-ID | <10c5b9g$1gfbn$1@dont-email.me> |
| In reply to | #188004 |
On 7/10/2025 2:58 am, Alan wrote: > On 2025-10-06 01:23, Daniel70 wrote: >> On 6/10/2025 3:16 pm, Alan wrote: >>> On 2025-10-05 19:46, Lars Poulsen wrote: >>>> Alan <nuh-uh@nope.com> wrote: >>>> Alan>>> If I do a similar thing on macOS, it's done almost before >>>> the files >>>> Alan>>> have finished the move >>>> >>>>> On 2025-10-01 13:19, Carlos E.R. wrote: >>>> Carlos>> Not if it does content indexing. >>>> >>>> Alan> If a file has already BEEN indexed for its content... >>>> Alan> ...why would simply moving it to a new location require it to >>>> be re-read? >>>> Alan> Did its content magically change just because you moved it? >>>> Alan> No. >>>> >>>> This is the difference between indexing on demand versus CONTINUOUSLY >>>> MAINTAINING an index. >>> >>> I'm sorry, but you're wrong. >>> >>> You index a file so that you can find it based on metadata and content. >>> >>> When a search happens, the INDEX gets searched the location of the >>> file is returned. >>> >>> The location of the file is ONE single piece of information in the >>> indexing system about the file. >>> >>> Move the file and all you need to do is update that one piece of >>> information. >>> >>> Nothing else has changed: not it's name, not it's date modified or >>> last opened, not it's content. >>> >>> So there is no need to re-read the file. >> >> How is your system supposed to know that the contents of the "new" >> "moved" file is *EXACTLY* the same as the original file (never had an >> individual Byte/Bit of RAM die on you??) .... unless it still HAS the >> "original" file to compare the new file too?? > > Oh dear GOD! > > You cannot be this ignorant. > > When you "move" a file from one directory to another on a partition, the > actual data of the file IS NOT TOUCHED. > > The individual bits of the file stay in exactly the same place. > > All that's changed is the file system's record of which directory the > file should be displayed as being in. > > Do you know what a "hard link" is? Alan, would you be satisfied if I had said/asked what happens when a File is 'COPIED' rather than 'MOVED'?? Would I end up with TWO copies of the File on my HD?? If I then deleted the ORIGINAL file, how do I *KNOW* that the remaining file is the same as the ORIGINAL file?? -- Daniel70
[toc] | [prev] | [next] | [standalone]
| From | "J. P. Gilliver" <G6JPG@255soft.uk> |
|---|---|
| Date | 2025-10-08 11:38 +0100 |
| Message-ID | <10c5eum$12qsu$9@dont-email.me> |
| In reply to | #188080 |
On 2025/10/8 10:35:43, Daniel70 wrote: [] > Alan, would you be satisfied if I had said/asked what happens when a > File is 'COPIED' rather than 'MOVED'?? > > Would I end up with TWO copies of the File on my HD?? Yes; for a COPY, you will definitely have to have two copies - because if you subsequently edited one of them, the first one would have to remain unchanged. The only alternative to that would be for the OS to keep a record of all copy operations you do, and then if you alter one of them, copy the original first anyway so that it remains unchanged; I know of no OS that does this (the trcking requirements would be horrendous!). You can easily check that: look at the reported space used/remaining before and after you do a copy. It will go up/down. (And you will eventually run out of space and it won't let you copy.) > > If I then deleted the ORIGINAL file, how do I *KNOW* that the remaining > file is the same as the ORIGINAL file?? You don't, unless you invoked the verify option (or it is on by default) when you did the copy. -- J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf "If god doesn't like the way I live, Let him tell me, not you." - unknown
[toc] | [prev] | [next] | [standalone]
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Date | 2025-10-08 08:23 -0700 |
| Message-ID | <10c5vlq$1m1kq$6@dont-email.me> |
| In reply to | #188080 |
On 2025-10-08 02:35, Daniel70 wrote: > On 7/10/2025 2:58 am, Alan wrote: >> On 2025-10-06 01:23, Daniel70 wrote: >>> On 6/10/2025 3:16 pm, Alan wrote: >>>> On 2025-10-05 19:46, Lars Poulsen wrote: >>>>> Alan <nuh-uh@nope.com> wrote: >>>>> Alan>>> If I do a similar thing on macOS, it's done almost before >>>>> the files >>>>> Alan>>> have finished the move >>>>> >>>>>> On 2025-10-01 13:19, Carlos E.R. wrote: >>>>> Carlos>> Not if it does content indexing. >>>>> >>>>> Alan> If a file has already BEEN indexed for its content... >>>>> Alan> ...why would simply moving it to a new location require it to >>>>> be re-read? >>>>> Alan> Did its content magically change just because you moved it? >>>>> Alan> No. >>>>> >>>>> This is the difference between indexing on demand versus CONTINUOUSLY >>>>> MAINTAINING an index. >>>> >>>> I'm sorry, but you're wrong. >>>> >>>> You index a file so that you can find it based on metadata and content. >>>> >>>> When a search happens, the INDEX gets searched the location of the >>>> file is returned. >>>> >>>> The location of the file is ONE single piece of information in the >>>> indexing system about the file. >>>> >>>> Move the file and all you need to do is update that one piece of >>>> information. >>>> >>>> Nothing else has changed: not it's name, not it's date modified or >>>> last opened, not it's content. >>>> >>>> So there is no need to re-read the file. >>> >>> How is your system supposed to know that the contents of the "new" >>> "moved" file is *EXACTLY* the same as the original file (never had an >>> individual Byte/Bit of RAM die on you??) .... unless it still HAS the >>> "original" file to compare the new file too?? >> >> Oh dear GOD! >> >> You cannot be this ignorant. >> >> When you "move" a file from one directory to another on a partition, >> the actual data of the file IS NOT TOUCHED. >> >> The individual bits of the file stay in exactly the same place. >> >> All that's changed is the file system's record of which directory the >> file should be displayed as being in. >> >> Do you know what a "hard link" is? > > Alan, would you be satisfied if I had said/asked what happens when a > File is 'COPIED' rather than 'MOVED'?? > > Would I end up with TWO copies of the File on my HD?? > > If I then deleted the ORIGINAL file, how do I *KNOW* that the remaining > file is the same as the ORIGINAL file?? Why would you do that? This thread is about why Windows needs to reindex the entire content of a file when the operation is a simple move.
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-10-06 04:52 -0400 |
| Message-ID | <10c000f$6i79$1@dont-email.me> |
| In reply to | #187984 |
On Mon, 10/6/2025 12:16 AM, Alan wrote: > On 2025-10-05 19:46, Lars Poulsen wrote: >> Alan <nuh-uh@nope.com> wrote: >> Alan>>> If I do a similar thing on macOS, it's done almost before the files >> Alan>>> have finished the move >> >>> On 2025-10-01 13:19, Carlos E.R. wrote: >> Carlos>> Not if it does content indexing. >> >> Alan> If a file has already BEEN indexed for its content... >> Alan> ...why would simply moving it to a new location require it to be re-read? >> Alan> Did its content magically change just because you moved it? >> Alan> No. >> >> This is the difference between indexing on demand versus CONTINUOUSLY >> MAINTAINING an index. > > I'm sorry, but you're wrong. > > You index a file so that you can find it based on metadata and content. > > When a search happens, the INDEX gets searched the location of the file is returned. > > The location of the file is ONE single piece of information in the indexing system about the file. > > Move the file and all you need to do is update that one piece of information. > > Nothing else has changed: not it's name, not it's date modified or last opened, not it's content. > > So there is no need to re-read the file. > There is one of those Microsoft-style descriptions here, of how it works. https://learn.microsoft.com/en-us/windows/win32/search/-search-indexing-process-overview https://learn.microsoft.com/en-us/windows/win32/fileio/change-journal-records Paul
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-10-06 14:17 +0200 |
| Message-ID | <gjocrlxipn.ln2@Telcontar.valinor> |
| In reply to | #187984 |
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. -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Date | 2025-10-06 09:12 -0700 |
| Message-ID | <10c0ppv$d6mu$4@dont-email.me> |
| In reply to | #187998 |
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.
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | alt.comp.os.windows-10
csiph-web