Locked file may have resulted in duplicated file?

[therube]

Locked file /may/ have resulted in duplicated file?
(Something happened, where I ended up with a dup'd file, though not certain just what.)


2 existing files

T:\_from_S\True12.mp4
W:\S\True12.mp4

wanted to rename both
selected both, Shift+F2 -> True12-ish

turns out the T file was "locked" (a handle to it was open [in FastCopy])
(FC opens handles to [256, i'm thinking it is] files [at a time] that it is dealing with [rather then using VSCS]
- which i hadn't realized)

so when i went to rename, found it very odd that on the T: file, the attempted rename failed
(which i did not know the reason for - at first)

... not quit sure what i did at that point (of Everything notification of fail) ?
i /think/ i aborted at that point (& thought odd... ?)
probably tried it again (only to fail again)
then i might have let the 1 file that would rename, rename,
but was still left with 1 file that had not renamed...

so i then tried that 1 file, singularly, & that still failed
(discovered the reason, handle open)

close the handle
renamed the file

at some point, re-opend the "handle" to the file (via FC)

& when i look, i'm left with TWO copies of the file in T:
- 1 with the original name, 1 the renamed name
- they are different files, different FID's, so not hardlinks

so i've ended up with the file, duplicated
- ODD thing is,
- both files have the same date modified (understandable) AND date created (odd...)


09.59 E:\Users\RUBEN\AppData\Roaming\Microsoft\Windows\Recent\True12-ish.mp4.lnk
08.55 W:\S\True12-ish.mp4
08.55 W:\S\True12.mp4
08.55 W:\S\True12.mp4
08.55 W:\S\True12.mp4
08.39 W:\S\True12-ish.mp4

for some reason, Index Journal is not showing T: info at all ?

is it possible that... possible, not sure, but don't think so
- actually, i CAN tell - from older Everything .db...
between 1288 & 1289, source file existed ONLY on T:
later, is was copied to W:\S\ (via FastCopy - & the file remained locked [handle], by chance)
& i can't imagine i interacted with it, i.e. copied it...,
except for now, when wanting to rename (both) files in Everything
(which has now turned into 4, 3 real & 1 fake ) [<- at this point, not sure what i meant by that?]

NOTE it is the SOURCE file on T: that has is "locked" (has its' handle open)

[NotNull]

- both files have the same date modified (understandable) AND date created (odd...)

Explanation by Raymond Chen about file system tunneling.
(I thought I already wrote about it on these forums, but can't find it; must be a different forum then)

Tunneling
NTFS uses the concept of tunneling to allow compatibility with older programs that depend on
the file system to cache certain file metadata for a period of time even after the file is gone,
such as when it has been deleted or renamed. With tunneling, any new file created with the
same name as the original file, and within a certain period of time, will keep some of the same
metadata. The idea is to replicate behavior expected by MS-DOS programs when using the safe
save programming method, in which modified data is copied to a temporary file, the origi-
nal file is deleted, and then the temporary file is renamed to the original name. The expected
behavior in this case is that the renamed temporary file should appear to be the same as the
original file, otherwise the creation time would continuously update itself with each modifica-
tion (which is how the modified time is used).
NTFS uses tunneling so that when a file name is removed from a directory, its long name and
short name, as well as its creation time, are saved into a cache. When a new file is added to a
directory, the cache is searched to see whether there is any tunneled data to restore. Because
these operations apply to directories, each directory instance has its own cache, which is de-
leted if the directory is removed. NTFS will use tunneling for the following series of operations if
the names used result in the deletion and re-creation of the same file name:
■ Delete + Create
■ Delete + Rename
■ Rename + Create
■ Rename + Rename
By default, NTFS keeps the tunneling cache for 15 seconds, although you can modify this
timeout by creating a new value called MaximumTunnelEntryAgeInSeconds in the HKLM\
SYSTEM\CurrentControlSet\Control\FileSystem registry key. Tunneling can also be completely
disabled by creating a new value called MaximumTunnelEntries and setting it to 0; however, this
will cause older applications to break if they rely on the compatibility behavior.
You can see tunneling in action with the following simple experiment in the command prompt:
1. Create a file called file1.
2. Wait for more than 15 seconds (the default tunnel cache timeout).
3. Create a file called file2.
4. Perform a dir /TC. Note the creation times.
5. Rename file1 to file.
6. Rename file2 to file1.
7. Perform a dir /TC. Note that the creation times are identical