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 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-08-17 18:15 -0400 |
| Message-ID | <107tkad$2kqp1$1@dont-email.me> |
| In reply to | #186816 |
On Sun, 8/17/2025 4:03 PM, Tom Elam wrote: > On 8/9/2025 7:30 PM, 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. > > I'm really glad Alan does not know how badly the move to Modern Sleep has screwed up what was a perfectly good Windows feature. This goes back to at least 2020. > > https://mspoweruser.com/microsofts-modern-standby-is-draining-certain-laptops/ > > In addition, some Windows machine are only able to perform Modern Sleep. Mine was one until I found a registry hack to enable Hibernation. > But that's really no different than regular ACPI failures. The "powercfg" utility, has some tools for collecting reports and finding "hints" of a root cause. In your example, since the machine is not entering a low power state, I would be checking LastWake to see it bouncing out of the low power state. The machine I'm typing on, draws 33W while idling in S0. Your example is 27.5W in fake Modern Standby, which means it is fully in S0. My machine includes a plugin video card (the inclusion of which was forced by a bug in the design). The lowest S0 Idle I've got, is a 6 core machine that runs idling at 22 watts (using its iGPU). Then you have all possible combinations of broken and working stuff. https://www.elevenforum.com/t/disable-modern-standby-in-windows-10-and-windows-11.3929/ The theme repeats over and over again with modern computers. Additional complexity, enlarged table of possibilities, and little to show for all of it. There is the potential (but not the guarantee) of a BIOS switch, to aid in changing ACPI model. And the worst case for laptops, is where the ACPI table has syntax errors, the Linux parser points out the problem, the manufacturer refuses (or is unable) to edit the BIOS and correct that part of it. It's not always possible, when purchasing, to catch problems like that before they sting you. Paul
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-10-01 22:19 +0200 |
| Message-ID | <50f0rlx42o.ln2@Telcontar.valinor> |
| In reply to | #186595 |
On 2025-08-10 01:30, Alan wrote: ... > > 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! No one is. It requires reading all bytes of every file and calculating a checksum. > > 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 Not if it does content indexing. -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Date | 2025-10-01 14:18 -0700 |
| Message-ID | <10bk5qs$k5d3$3@dont-email.me> |
| In reply to | #187873 |
On 2025-10-01 13:19, Carlos E.R. wrote: > On 2025-08-10 01:30, Alan wrote: > > ... > >> >> 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! > > No one is. It requires reading all bytes of every file and calculating a > checksum. It absolutely does not. > >> >> 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 > > Not if it does content indexing. Wrong. Completely and utterly wrong.
[toc] | [prev] | [next] | [standalone]
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Date | 2025-10-05 15:01 -0700 |
| Message-ID | <10buprg$3qnvn$1@dont-email.me> |
| In reply to | #187873 |
On 2025-10-01 13:19, Carlos E.R. wrote: > On 2025-08-10 01:30, Alan wrote: > > ... > >> >> 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! > > No one is. It requires reading all bytes of every file and calculating a > checksum. Nope. That is NOT what content indexing even does. And even if you're using checksums for file integrity checking, moving a file from one directory to another in the file system shouldn't trigger one... ...because the file ITSELF isn't being rewritten. > >> >> 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 > > Not if it does content indexing. > Carlos: If a file has already BEEN indexed for its content... ...why would simply moving it to a new location require it to be re-read? Did its content magically change just because you moved it? No.
[toc] | [prev] | [next] | [standalone]
| From | Lars Poulsen <lars@cleo.beagle-ears.com> |
|---|---|
| Date | 2025-10-06 02:46 +0000 |
| Message-ID | <slrn10e6bct.2l7ki.lars@cleo.beagle-ears.com> |
| In reply to | #187979 |
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 suspect that one can set Windows to do either. But the overhead is different between the two. I have indeing turned off on my Windows systems. -- Lars Poulsen
[toc] | [prev] | [next] | [standalone]
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Date | 2025-10-05 21:16 -0700 |
| Message-ID | <10bvfri$1q6o$1@dont-email.me> |
| In reply to | #187983 |
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. > > I suspect that one can set Windows to do either. But the overhead is > different between the two. > > I have indeing turned off on my Windows systems. Because it works so poorly. I can move a directory containing 10,000 files in various sub-directories and as soon as the move is finished, my macOS Spotlightâ„¢ indexing system will find them in their new location with (essentially) no delay. If you don't believe me, I can demonstrate.
[toc] | [prev] | [next] | [standalone]
| From | Daniel70 <daniel47@nomail.afraid.org> |
|---|---|
| Date | 2025-10-06 19:23 +1100 |
| Message-ID | <10bvua3$65if$1@dont-email.me> |
| In reply to | #187984 |
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?? -- Daniel70
[toc] | [prev] | [next] | [standalone]
| From | MikeS <MikeS@fred.com> |
|---|---|
| Date | 2025-10-06 09:56 +0100 |
| Message-ID | <10c008n$6g8g$1@dont-email.me> |
| In reply to | #187989 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Daniel70 <daniel47@nomail.afraid.org> |
|---|---|
| Date | 2025-10-06 20:54 +1100 |
| Message-ID | <10c03kh$7c3s$1@dont-email.me> |
| In reply to | #187991 |
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. -- Daniel70
[toc] | [prev] | [next] | [standalone]
| From | Brian Gregory <void-invalid-dead-dontuse@email.invalid> |
|---|---|
| Date | 2025-10-06 15:59 +0100 |
| Message-ID | <mki3qoF4elcU1@mid.individual.net> |
| In reply to | #187992 |
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. You're being silly. It's not the job of software to continuously expend lots of effort just so that it can carry on as if nothing has happened if and when at some point in the future the hardware starts to fail. -- Brian Gregory (in England).
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-10-06 22:35 +0200 |
| Message-ID | <ppldrlx9e8.ln2@Telcontar.valinor> |
| In reply to | #188003 |
On 2025-10-06 16:59, Brian Gregory 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. > > You're being silly. > > It's not the job of software to continuously expend lots of effort just > so that it can carry on as if nothing has happened if and when at some > point in the future the hardware starts to fail. Actually, it is. There are advanced filesystems that certify that files do not change "accidentally". -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Date | 2025-10-06 13:53 -0700 |
| Message-ID | <10c1a8r$h6gk$1@dont-email.me> |
| In reply to | #188021 |
On 2025-10-06 13:35, Carlos E.R. wrote: > On 2025-10-06 16:59, Brian Gregory 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. >> >> You're being silly. >> >> It's not the job of software to continuously expend lots of effort >> just so that it can carry on as if nothing has happened if and when at >> some point in the future the hardware starts to fail. > > Actually, it is. > > There are advanced filesystems that certify that files do not change > "accidentally". > But MOVING a file has NOTHING TO DO WITH THAT! A "move" on a volume is nothing more than changing which directory a file will appear in. The actually data on the drive ISN'T MOVED!!!
[toc] | [prev] | [next] | [standalone]
| From | Daniel70 <daniel47@nomail.afraid.org> |
|---|---|
| Date | 2025-10-08 20:12 +1100 |
| Message-ID | <10c59ta$1g55n$1@dont-email.me> |
| In reply to | #188003 |
On 7/10/2025 1:59 am, Brian Gregory 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. > > You're being silly. > > It's not the job of software to continuously expend lots of effort just > so that it can carry on as if nothing has happened if and when at some > point in the future the hardware starts to fail. > Correct. So the OP COULD have checked/compared the ORIGINAL file with the RELOCATED to ensure they are IDENTICAL ..... but, somehow, I don't think the SOFTWARE/OS does that check. -- Daniel70
[toc] | [prev] | [next] | [standalone]
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Date | 2025-10-08 08:18 -0700 |
| Message-ID | <10c5vb9$1m1kq$1@dont-email.me> |
| In reply to | #188072 |
On 2025-10-08 02:12, Daniel70 wrote:
> On 7/10/2025 1:59 am, Brian Gregory 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.
>>
>> You're being silly.
>>
>> It's not the job of software to continuously expend lots of effort
>> just so that it can carry on as if nothing has happened if and when at
>> some point in the future the hardware starts to fail.
>>
> Correct. So the OP COULD have checked/compared the ORIGINAL file with
> the RELOCATED to ensure they are IDENTICAL ..... but, somehow, I don't
> think the SOFTWARE/OS does that check.
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:59 -0700 |
| Message-ID | <10c0p0n$d6mu$2@dont-email.me> |
| In reply to | #187992 |
On 2025-10-06 02: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. And it would mean the same for a file you DIDN'T move.
[toc] | [prev] | [next] | [standalone]
| From | Daniel70 <daniel47@nomail.afraid.org> |
|---|---|
| Date | 2025-10-08 20:18 +1100 |
| Message-ID | <10c5a8r$1g7i2$1@dont-email.me> |
| In reply to | #188005 |
On 7/10/2025 2:59 am, Alan wrote: > On 2025-10-06 02: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. > > And it would mean the same for a file you DIDN'T move. Sorry! WHAT?? A file THAT I'VE DONE NOTHING TO might change! Really?? WHEN?? WHY?? At some indeterminate time in the future?? SURE!! -- Daniel70
[toc] | [prev] | [next] | [standalone]
| From | "J. P. Gilliver" <G6JPG@255soft.uk> |
|---|---|
| Date | 2025-10-08 11:16 +0100 |
| Message-ID | <10c5dlh$12qsu$8@dont-email.me> |
| In reply to | #188075 |
On 2025/10/8 10:18:17, Daniel70 wrote: [] > Sorry! WHAT?? A file THAT I'VE DONE NOTHING TO might change! > > Really?? Yes; it's called bit-rot, among other things.> > WHEN?? Depends on many factors; generally thought of as being possibly 5-10 years for hard drives and SSDs, though the latter haven't _really_ been around for long enough for other than accelerated testing. Optical discs depends greatly on quality of disc, and storage conditions; my experience (mostly with budget ones) is not hopeful for more than a few (single digit number of) years. In practice, these are the times after which the error-correcting fails; individual bits probably rot sooner, but are correctable - until they aren't. > > WHY?? Hard (and floppy) discs - areas magnetised lose or gain difference from adjacent ones. SSDs - charge leaks away (or in). Optical discs - the dye fades and similar (especially if not kept away from light). > > At some indeterminate time in the future?? Yes. > > SURE!! Indeed! About the only reliable medium (for computer data, anyway - printed paper isn't bad, either) is punched plastic tape, but the information density is horrendous. (And not proof against e. g. fire.) -- 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 | MikeS <MikeS@fred.com> |
|---|---|
| Date | 2025-10-06 17:28 +0100 |
| Message-ID | <10c0qnf$dln5$1@dont-email.me> |
| In reply to | #187992 |
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. File indexing systems CANNOT record and search for data corruption.
[toc] | [prev] | [next] | [standalone]
| From | Alan <nuh-uh@nope.com> |
|---|---|
| Date | 2025-10-06 09:33 -0700 |
| Message-ID | <10c0r16$d6mt$1@dont-email.me> |
| In reply to | #188011 |
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. File > indexing systems CANNOT record and search for data corruption. THANK YOU!
[toc] | [prev] | [next] | [standalone]
| From | Daniel70 <daniel47@nomail.afraid.org> |
|---|---|
| Date | 2025-10-08 20:23 +1100 |
| Message-ID | <10c5ahv$1g9ss$1@dont-email.me> |
| In reply to | #188012 |
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!! >> File indexing systems CANNOT record and search for data >> corruption. > > THANK YOU! > For what?? -- Daniel70
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | alt.comp.os.windows-10
csiph-web