When replacing files, the "new" take the created date of the replaced ones

Please check the FAQ (https://www.xyplorer.com/faq.php) before posting a question...
Post Reply
1024mb
Posts: 205
Joined: 14 Dec 2018 23:26

When replacing files, the "new" take the created date of the replaced ones

Post by 1024mb »

Has anyone noticed this?

I have:

Code: Select all

Folder A \
                Name A.bin <- Created date 05-06-2021 14:00:00
                Name B.bin <- Created date 04-06-2021 11:00:00

Folder B \
               Name A.bin <- Created date 01-02-2002 10:00:00
               Name B.bin <- Created date 03-03-2003 14:00:00
Then when I replace the files in folder B for the files in folder A, it doesn't matter if I move the files and choose to replace them or if I first delete the files in Folder B and then I move the other files, the "new" files will take the date of the replaced ones so it will end like:

Code: Select all

Folder A \
                 <------- EMPTY ------->

Folder B \
               Name A.bin <- Created date 01-02-2002 10:00:00
               Name B.bin <- Created date 03-03-2003 14:00:00
The modified and accessed dates are left intact but I don't know why the files take the created date from the replaced files, and no is not XYplorer not updating the column, I've right clicked - Properties and looked at the dates there. Also, I've only noticed this happening when the files have the exact same name and extension (like in the example). And this is happening only in XYplorer, I've just tried M$' Explorer and this doesn't happened, then I tried with a clean XYplorer instance and it happened.

Can anybody please test this and confirm I haven't fucked up my XY config? :mrgreen:

notabot
Posts: 59
Joined: 24 Feb 2021 12:34

Re: When replacing files, the "new" take the created date of the replaced ones

Post by notabot »

1024mb wrote: 05 Jun 2021 20:52 Can anybody please test this and confirm I haven't fucked up my XY config?
I didn't test it, but this an NTFS filesystem feature and it is called File System Tunneling.
It basically caches some metadata of a file (like your date created) for older programs that use a delete+create process instead of for example rename. Or when saving an updated file: save to temp-file, delete original and rename tempfile to original.
Otherwise all the metadata would be gone.
So when a new file is created, Windows checks the cache to see if it contains that specific filename and adds all the existing metadata to the new file.

The default caching time is 15 seconds, so you can test the following:
[1] Ddelete file, wait 15 seconds (or to be save: 20 seconsds) and copy/move your file
[2] Try your original action on a non-NTFS filesystem (FAT32, exFAT, ...)

If my theory is correct, in both cases the new file should not inherit the date created attribute.

It is possible to shorten the caching period - or even completely disable it altogether - through a regkey, but at the moment I'm too lazy to look it up :) But 'Internet' should know ..

1024mb
Posts: 205
Joined: 14 Dec 2018 23:26

Re: When replacing files, the "new" take the created date of the replaced ones

Post by 1024mb »

Now that you mention I remember reading about it years ago but I totally forgot about it, what it's weird is that I haven't noticed this before, maybe I've always done all the operations with more than 15 seconds in between them? :eh:

Anyway, after reading more about File System Tunneling I found this: https://devblogs.microsoft.com/oldnewth ... 4/?p=34923 it warns about disabling it as it may break some apps:
When you use a program to edit an existing file, then save it, you expect the original creation timestamp to be preserved, since you’re editing a file, not creating a new one. But internally, many programs save a file by performing a combination of save, delete, and rename operations (such as the ones listed in the linked article), and without tunneling, the creation time of the file would seem to change even though from the end user’s point of view, no file got created.
But that's from 2005 and short names are mostly used by 16-bit applications so that doesn't apply any more? Even so shortening it to 1 or 2 seconds should do the job but I think I'll try disabling all together and will keep and eye for any application misbehaving.

Thanks for the info.

1024mb
Posts: 205
Joined: 14 Dec 2018 23:26

Re: When replacing files, the "new" take the created date of the replaced ones

Post by 1024mb »

Buuuut. Why is this not happening on M$ Explorer? I've tried with that and it didn't happened, the files preserved their creation dates, it is only happening with XYplorer. I guess I will have to wait until you or someone else can confirm this.

I've just tried it again and yes, it only happens with XYplorer. I'm not taking more than 15 seconds as I'm not deleting any file and then moving, I'm replacing them in situ.

notabot
Posts: 59
Joined: 24 Feb 2021 12:34

Re: When replacing files, the "new" take the created date of the replaced ones

Post by notabot »

1024mb wrote: 06 Jun 2021 00:56 and short names are mostly used by 16-bit applications so that doesn't apply any more?
Explorer (shell) still uses it on occasion as a fallback for drag 'n drop of long paths/filenames (> 259 characters). It replaces the long filenames with the 8.3 one.
IIRC, it is also used for shell extensions ('the context menu') when the old (XP-era) API's are used in combination with long filenames. But not entirely sure ..


FWIW: about 2 years ago, I disabled 8.3 filenames on my system and removed all short filenames attributes for all files/folders and found no issues whatsoever. But I don't use long paths.
After the next major Windows update, 8.3 filenames were enabled again, so I could start all over again ... :cry:

Post Reply