Folder 'Date Modified' EARLIER than 'Date Created'

Paul Black · 30 Aug 2022

I do NOT know how long this has been happening, but I just noticed it today.

The problem appears to be related to just folders, and NOT files.

When I create a NEW folder, the 'Date Created' and 'Date Modified' are the SAME.

I have a Script that I created that I run once a day, or whenever I want, that backs up two folders with sub-folders. This has NOTHING to do with the Script, I am just using it as an example as it was easier to run in order to show what I mean.

I have just run it [ 30-Aug-2022 at 21:11 ].

This shows the main folders, and the 'Date Created' and 'Date Modified' are the SAME. . . .

Folder 'Date Modified' EARLIER than 'Date Created'-image.png

This shows the FIRST folder, and the 'Date Modified' is TWO days ago and about 11 hours earlier than the 'Date Created' . . .

The SECOND folder is just .log files and are OK.

This shows the THIRD folder, and the 'Date Modified' is about 3.75 hours earlier than the 'Date Created' . . .

The Date & Time shown in the folders above is CORRECT.

The clock shows the CORRECT Date & Time for the UK.

Has anyone got any ideas please ?

Paul Black · 30 Aug 2022

Looking back at my custom install notes, I see that I changed the following Registry Entry as per one of @Brink's excellent Tutorials . . .

> How to Enable or Disable NTFS Last Access Time Stamp Updates in Windows 10

This is the Registry file I used . . .

Code:


Windows Registry Editor Version 5.00

; Created by: Shawn Brink
; Created on: August 22nd 2019
; Tutorial  : https://www.tenforums.com/tutorials/139015-enable-disable-ntfs-last-access-time-stamp-updates-windows-10-a.html

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"NtfsDisableLastAccessUpdate"=dword:80000002

The Registry Entry was previously "NtfsDisableLastAccessUpdate"=dword:80000000.

I wonder if it has anything to do with that.

Here is the full Exported Registry Key . . .

Code:


Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"DisableDeleteNotification"=dword:00000001
"FilterSupportedFeaturesMode"=dword:00000000
"LongPathsEnabled"=dword:00000000
"NtfsAllowExtendedCharacter8dot3Rename"=dword:00000000
"NtfsBugcheckOnCorrupt"=dword:00000000
"NtfsDisable8dot3NameCreation"=dword:00000002
"NtfsDisableCompression"=dword:00000000
"NtfsDisableEncryption"=dword:00000000
"NtfsDisableLastAccessUpdate"=dword:80000002 <--- Changed to as per Tutorial
"NtfsDisableLfsDowngrade"=dword:00000000
"NtfsDisableVolsnapHints"=dword:00000000
"NtfsEncryptPagingFile"=dword:00000000
"NtfsMemoryUsage"=dword:00000000
"NtfsMftZoneReservation"=dword:00000000
"NtfsQuotaNotifyRate"=dword:00000e10
"RefsDisableLastAccessUpdate"=dword:00000001
"ScrubMode"=dword:00000001
"SymlinkLocalToLocalEvaluation"=dword:00000001
"SymlinkLocalToRemoteEvaluation"=dword:00000001
"SymlinkRemoteToLocalEvaluation"=dword:00000000
"SymlinkRemoteToRemoteEvaluation"=dword:00000000
"UdfsCloseSessionOnEject"=dword:00000003
"UdfsSoftwareDefectManagement"=dword:00000000
"Win31FileSystem"=dword:00000000
"Win95TruncatedExtensions"=dword:00000001
"RefsDisableDeleteNotification"=dword:00000001

I will investigate further tomorrow.

LesFerch · 30 Aug 2022

The Date accessed registry values have nothing to do with it. I can replicate what you're seeing by copying a folder that has a Date modified value that is earlier than today to another disk using a command such as Robocopy C:\SomeDir D:\SomeDir /mir. The destination folder will have the old Date modified date, but today's date for Date created.

Paul Black · 31 Aug 2022

Hello @LesFerch,

LesFerch said:

The Date accessed registry values have nothing to do with it. I can replicate what you're seeing by copying a folder that has a Date modified value that is earlier than today to another disk using a command such as Robocopy C:\SomeDir D:\SomeDir /mir. The destination folder will have the old Date modified date, but today's date for Date created.

Brilliant, that is exactly what the answer is.

I have just compared the original folders 'Date Created' and 'Date Modified' to the NEW folders 'Date Created' and 'Date Modified', and they tie up EXACTLY. I am using Robocopy by the way.

Solved.

Thank you.

hdmi · 31 Aug 2022

This is one of those numerous reasons why I always use FastCopy instead of Robocopy. The Date created of the source folder gets preserved during data duplication tasks, and, you get a log file that contains actual decent logging information (instead of one that is essentially useless).

LesFerch · 31 Aug 2022

hdmi said:

This is one of those numerous reasons why I always use FastCopy instead of Robocopy. The Date created of the source folder gets preserved during data duplication tasks, and, you get a log file that contains actual decent logging information (instead of one that is essentially useless).

Actually, RoboCopy will preserve Date created for all folders (including the top level destination folder) with the addition of the /DCOPY:T switch. Using our example, the command would be:

robocopy c:\somedir d:\somedir /mir /dcopy:t

In testing FastCopy, I found that it preserves Date created for files and subfolders, but not for the top level folder (i.e. DestDir). Is there an option in FastCopy to make DestDir have the same Date created as Source?

hdmi · 31 Aug 2022

LesFerch said:

Actually, RoboCopy will preserve Date created for all folders (including the top level destination folder) with the addition of the /DCOPY:T switch. Using our example, the command would be:

robocopy c:\somedir d:\somedir /mir /dcopy:t

The /dcopy:t switch does not always have the effect that we specifically are aiming for here, see: windows 7 - robocopy with DCOPY:T does not work - Super User

In testing FastCopy, I found that it preserves Date created for files and subfolders, but not for the top level folder (i.e. DestDir). Is there an option in FastCopy to make DestDir have the same Date created as Source?

No, not directly, at least not that I am aware of. But the /postproc switch allows you to specify a custom action that will be executed after the job ends, so I guess you could still easily figure a way to work around that.

LesFerch · 31 Aug 2022

hdmi said:

The /dcopy:t switch does not always have the effect that we specifically are aiming for here, see: windows 7 - robocopy with DCOPY:T does not work - Super User

I can't reproduce the issue described in that very old thread. I tested Robocopy with folders containing many nested subfolders. The /DCOPY:T switch preserved the folder dates in all tests. I have to conclude it's an old bug that was fixed years ago. Can you reproduce the issue?

Paul Black · 01 Sep 2022

The /COPY:DAT switch is the Default switch so does NOT need to be included in the command line.

What is the advantage of using /DCOPY:T as opposed to /COPY:T please as I did NOT have either in my command line ?

Code:


/copy:<copyflags>	Specifies which file properties to copy. The valid values for this option are:

D - Data
A - Attributes
T - Time stamps
S - NTFS access control list (ACL)
O - Owner information
U - Auditing information

The default value for this option is DAT (data, attributes, and time stamps).

After your explanation @LesFerch to my original post, which I should have known [ old age ], the output I was getting with regard to Date & Time was absolutely fine.

For one Script I just use RoboCopy "%Src1%" "%Des1%" /MIR /W:1 /LOG:"%Log1%" >nul 2>&1

I do like RoboCopy as it has a lot of Parameters / Switches available in which to use for the task in hand.

Thanks.

hdmi · 01 Sep 2022

Paul Black said:

What is the advantage of using /COPY:T as opposed to /COPY:DAT

/DCOPY:T not /COPY:T
It's supposed to make sure that the Date created of the source folder always gets copied along, i.e., to prevent the current datetime from being copied onto the destination (and/or onto one or more of its subfolders) instead.

I do like RoboCopy as it has a lot of Parameters / Switches available in which to use for the task in hand.

FastCopy has a lot of parameters/switches too. Some of the main benefits of FastCopy are
the ability to use hash codes like MD5 for verification,
the ability to store hash codes (either as alternate data streams or in the error log file) and
the fact that the logging capability is much, MUCH more mature compared to Robocopy. The latter will choke on special characters used in filenames/foldernames as far as the logging goes and will not even produce error log entries on a per file basis. So, it is about equally as primitive as Fred Flintstone's car. Granted, it's still a fast car, with the /MT switch especially, and especially if you also like to experiment with raising the number of threads above 8 (the default number if no number is specified after the /MT).
@LesFerch
I can't reproduce it right now, but IIRC when copying very large amounts of data (much more than several TB worth) it still has a bad tendency to flake out occasionally. One person in that old thread I linked has reported in 2017 that the issue still occurs if the /MT switch is used, and, even though I suppose it would be fair to claim that you can still always resume after an error, the simple fact remains that the error logging capability of Robocopy is just too poor to be able to entirely justify this claim, ESPECIALLY in view of this OTHER fact, that it offers no option to store and use MD5 hash codes for file verification. FastCopy is free also, so... why still bother with Robocopy? Is it because it is built-in? You know... the bottom of Fred Flintstone's car also has a built-in hole. lol