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.
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.
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!
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.
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?
On 6/10/2025 11:22 pm, Carlos E.R. wrote:
On 2025-10-06 10:23, Daniel70 wrote:So are you, Carlos, suggesting that, at the time of the move/copy, the
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.
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!!
Sorry! WHAT?? A file THAT I'VE DONE NOTHING TO might change!Yes; it's called bit-rot, among other things.>
Really??
WHEN??Depends on many factors; generally thought of as being possibly 5-10
WHY??Hard (and floppy) discs - areas magnetised lose or gain difference from adjacent ones. SSDs - charge leaks away (or in). Optical discs - the dye
At some indeterminate time in the future??Yes.
SURE!!Indeed!
On 2025-10-06 14:25, Carlos E.R. wrote:
On 2025-10-06 23:12, Alan wrote:A move to another volume is never really a move, now is it?
On 2025-10-06 13:47, Carlos E.R. wrote:
On 2025-10-06 18:12, Alan wrote:
On 2025-10-06 05:17, Carlos E.R. wrote:
On 2025-10-06 06:16, Alan wrote:
Move the file and all you need to do is update that one piece of >>>>>>> information.
For that you need a system service that tracks moves and tells the >>>>>> indexer. It doesn't happen automatically.
And why would that be at all difficult?
You have a journaled file system, so all you need is a process that >>>>> checks for events in the journal that actually DO mean that there
is a new file that's been created or that a file has been changed.
Those events require that a file get re-indexed. Moving a file
within the same volume does NOT.
That process on macOS is called "fseventsd"
Look it up.
Not going to look it up, I don't do macs. I'll accept your word.
Does Windows do it?
Apparently not.
Which is why I wrote subject I did:
"It is stunning when you see how badly Windows operates: indexing"
Well, I know that I have moved in the past huge content in Linux and
seen several content indexers re-index them. I would have to test
again noticing if it was the same partition.
The OS can make the end result appear to be the SAME as a move, but if
you want the files on a different volume, then the data in those files
will have to be WRITTEN to that new volume and of course the indexing
for that volume will have no entries for those files...
...because from the context of that new volume…
...THEY WILL BE NEW FILES.
On 2025-10-08 11:30, Daniel70 wrote:[]
(Hmm, arguably that's not a move, though it looks like one to the user -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.Indeed. The _checksums_ (or more complex equivalents) may well be
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 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.
Alan, would you be satisfied if I had said/asked what happens when aYes; for a COPY, you will definitely have to have two copies - because
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 remainingYou don't, unless you invoked the verify option (or it is on by default)
file is the same as the ORIGINAL file??
On Mon, 10/6/2025 8:27 PM, Alan wrote:
Paul, you're the idiot that claimed moving a file resulted in a "deletefile" in the USN Journal...
...and you were spectacularly wrong.
Here is some CoPilot feedback.
[Picture]
https://i.postimg.cc/J4qxv3Wn/Co-Pilot-Comment-On-USN.gif
[Picture]
https://i.postimg.cc/6pV8Yzs0/USN-move-testcase.gif
Paul
Surely this can't be so .... or has Copilot just not completed the process??
On 7/10/2025 1:59 am, Brian Gregory wrote:
On 06/10/2025 10:54, Daniel70 wrote:Correct. So the OP COULD have checked/compared the ORIGINAL file with
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.
the RELOCATED to ensure they are IDENTICAL ..... but, somehow, I don't
think the SOFTWARE/OS does that check.
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!!
On 6/10/2025 11:22 pm, Carlos E.R. wrote:
On 2025-10-06 10:23, Daniel70 wrote:So are you, Carlos, suggesting that, at the time of the move/copy, the
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.
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!!
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:So are you, Carlos, suggesting that, at the time of the move/copy, the
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.
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.
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.>
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.>
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 theA lot of (all modern, even floppy?) systems - hard disc drives, probably
metadata, so that integrity can be verified. It is not the default.
SSDs - do that at a low level anyway, as their error-correction mechanism.>
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??
On 7/10/2025 10:55 am, Alan wrote:
On 2025-10-06 14:25, Carlos E.R. wrote:
On 2025-10-06 23:12, Alan wrote:A move to another volume is never really a move, now is it?
On 2025-10-06 13:47, Carlos E.R. wrote:
On 2025-10-06 18:12, Alan wrote:
On 2025-10-06 05:17, Carlos E.R. wrote:
On 2025-10-06 06:16, Alan wrote:
Move the file and all you need to do is update that one piece of >>>>>>>> information.
For that you need a system service that tracks moves and tells
the indexer. It doesn't happen automatically.
And why would that be at all difficult?
You have a journaled file system, so all you need is a process
that checks for events in the journal that actually DO mean that
there is a new file that's been created or that a file has been
changed.
Those events require that a file get re-indexed. Moving a file
within the same volume does NOT.
That process on macOS is called "fseventsd"
Look it up.
Not going to look it up, I don't do macs. I'll accept your word.
Does Windows do it?
Apparently not.
Which is why I wrote subject I did:
"It is stunning when you see how badly Windows operates: indexing"
Well, I know that I have moved in the past huge content in Linux and
seen several content indexers re-index them. I would have to test
again noticing if it was the same partition.
The OS can make the end result appear to be the SAME as a move, but if
you want the files on a different volume, then the data in those files
will have to be WRITTEN to that new volume and of course the indexing
for that volume will have no entries for those files...
...because from the context of that new volume…
...THEY WILL BE NEW FILES.
So when DO those files that YOU have WRITTEN to that new volume actually
get listed in the content of that new volume??
And when do they get deleted from the original volume .... and de-
Indexed, of course??
On Wed, 10/8/2025 7:01 AM, Daniel70 wrote:
Surely this can't be so .... or has Copilot just not completed the process??
You can make up cases and ask the AI for a result.
The idea of making my stupid cases, is just to get it
to dump the names of a representative set of possibilities.
To move a file can:
1) Require deleting it with a change journal event,
then create it with a second change journal event.
The AI tells us there is no single-event Move type for the job.
There is a tendency in computer systems designs to use
atomic events rather than "do fancy stuff". There is a lot of
fancy stuff we could do, which in the end we don't do.
2) Moves can be orchestrated by the Name Change set of change journal events.
Now, you have to prepare your set of file names, and then
figure out which of those cases apply. Take the actual move
command that demonstrated a problem and get the AI description
of how that would be coded.
The journal dumps I've tried, at some point the design must
have changed. I didn't make a fetish out of this. Like at
one time, you could see a write-file event dumped, for
every 256KB or so of data. I don't think that scheme was
in the latest try I made of a dump.
******************
CoPilot Question
In the NTFS change journal, has the design of the journal events been a
constant with time or did the change journal design or representation change over the years ?
CoPilot Answer
The NTFS Change Journal - also known as the USN Journal - has evolved over time,
though its core purpose has remained consistent: to efficiently track
changes to files and directories on an NTFS volume.
### 🕰️ Evolution of the Change Journal Design
Here’s how its design and representation have changed over the years:
#### 1. **Initial Introduction (Windows 2000 / NTFS 3.0)**
- The Change Journal was introduced with NTFS 3.0.
- It stored records in a metafile called `$Extend\$UsnJrnl`.
- Each record included:
- A 64-bit Update Sequence Number (USN)
- File reference number
- Reason flags (bitmask indicating the type of change)
- Timestamp
- File name
#### 2. **USN_RECORD Structure Versions**
- Over time, Microsoft introduced new versions of the `USN_RECORD` structure:
- **V2**: Used in early implementations (Windows 2000, XP, etc.)
- **V3 and V4**: Introduced in later versions of Windows to support new features and metadata
- These versions added fields like extended reason flags, source info, and more precise timestamps.
#### 3. **Bit Flags Expansion**
- The `Reason` field uses bit flags like `USN_REASON_DATA_OVERWRITE`, `USN_REASON_FILE_CREATE`, etc.
- New flags were added over time to reflect more granular changes (e.g., file renames, ACL changes).
#### 4. **Performance and Scalability Enhancements**
- As file systems grew to support millions of files, the journal’s internal mechanisms were optimized for speed and reduced overhead.
- Journals became more configurable (e.g., size limits, retention policies).
#### 5. **Integration with New Features**
- Windows features like **File History**, **Windows Search**, and **Backup utilities** began leveraging the Change Journal.
- This led to more robust APIs and better documentation for developers.
---
### 🔍 Summary
While the fundamental concept of logging file system changes has stayed the same,
the **structure**, **metadata**, and **integration points** of the NTFS Change Journal
have evolved to meet the demands of modern systems. It’s a great example of a
foundational technology quietly adapting behind the scenes.
Would you like to dive into the specifics of the USN_RECORD structure versions
or how backup tools use the journal today? **********************************8
Paul
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,073 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 215:51:59 |
| Calls: | 13,783 |
| Calls today: | 1 |
| Files: | 186,987 |
| D/L today: |
345 files (78,771K bytes) |
| Messages: | 2,434,667 |
