All files suddenly have a 1 hour newer "modified" timestamp??

I regularly back up most of my files using robocopy using the mirror function.

Usually this is quick as it only copies the files that have changed since the rpevious backup.

I haven't noticed anything in the past days, since I most frequently backup to another SSD so it is very fast no matter what. But to my horror, when today I decided to backup to a relatively slow USB stick, it began copying everything anew!

I suddenly realized that it was because every single file on the USB-stick was 1 hour older than all the files on my SSD.

The last time I backed up to this USB stick was about one week ago, so something must have happened in the last week to set the modified timestamp of every single file on my SSD one hour later than they were before.

What could possibly be responsible for this? I don't recall playing with the date-and-time settings in Windows, but...

And why should it change the timestamp? I could maybe understand Windows interpreting the timestamp differently, but then surely it should also interpret the files on the USB-stick as having the same timestamp. So it seems that every file must have been individually touched?

Okay... thanks for the input though.

I just wanted to mention what's weird is that when instead of Windows Explorer, I use the command line WMIC DATAFILE [...] get LastModified on each file, then it doesn't say that the files are 1 hour apart, but instead 2 seconds! Still with the files backed up last week being the ones having the older timestamp value.

Try3 said:

/FFT - This makes RoboCopy deal with differences of a few seconds between files [I don't properly understand this switch but it was part of the successful solution so I'm keeping it in].

My understanding of this is that NTFS (as a journaling filesystem) uses tick counts whilst FAT systems just don't have that precision, hence stick to a 2 second median. Using the /FFT parameter apparently means 'don't be so fussy about datestamps' (to reduce file processing overhead) .However, I haven't used Robocopy for a long, long time so I could be wrong.

Subhuti said:

I regularly back up most of my files using robocopy using the mirror function.

Usually this is quick as it only copies the files that have changed since the rpevious backup.

I haven't noticed anything in the past days, since I most frequently backup to another SSD so it is very fast no matter what. But to my horror, when today I decided to backup to a relatively slow USB stick, it began copying everything anew!

I suddenly realized that it was because every single file on the USB-stick was 1 hour older than all the files on my SSD.

The last time I backed up to this USB stick was about one week ago, so something must have happened in the last week to set the modified timestamp of every single file on my SSD one hour later than they were before.

What could possibly be responsible for this? I don't recall playing with the date-and-time settings in Windows, but...

And why should it change the timestamp? I could maybe understand Windows interpreting the timestamp differently, but then surely it should also interpret the files on the USB-stick as having the same timestamp. So it seems that every file must have been individually touched?

For these situations there exists this program Freeware downloads: ITSTH - RightTime 1.00 review and download, With RightTime you can make all files in a directory tree on hour older/younger. . Executable name is "RightTime.exe" and I've been able to locate it searching exactly for that, quotes included. I've downloaded it just now to my W10 system and FC.EXE-compared it to my file, stored among my files since 2013 at least, and turned out equal. I've also run it and it seems to work, although I have just launched it, I haven't done any operation. Firefox or whatever behind it (Windows or my firewall/antivirus) asked me confirmation of the download for security reasons (a step that I've also seen with modern but unfrequently downloaded files, all legal).

According to its properties -> details page, it's from 2002 and its description is "MFC-Anwendung RightTime". I've added a "readme.txt" file with the following (I use to do this):

Anwendung RightTime is used to correct the, usually advanced or delayed one hour, modification date/time of files affected by certain defects in the management of DST, for example when recording and recovering them from external media with certain filesystems. It is a very basic program, without any intelligence to detect incorrect dates and times or select files on its own. To use it you just have to know if you have to advance or delay (one hour) the date and time of the files in a certain folder (all, subdirectories included).

Try3 said:

Both the one-hour difference in File explorer and the WMIC results sound to me like your Daylight saving time has started since your last backup.

/DST - This makes RoboCopy cope with Daylight saving time differences.
/FFT - This makes RoboCopy deal with differences of a few seconds between files [I don't properly understand this switch but it was part of the successful solution so I'm keeping it in].

RoboCopy - MSLearn

I am sorry I have been absent for some weeks, and then I come back to see this cornucopia of pertinent information!

I tried adding both the switches /DST and /FFT.

AND IT WORKED!!!

Phew!!!

Thank you to you and to everyone else!


It would also be interesting to know whether robocopy then won't copy files until the timestamp indicates are a a whole day earlier or later, or whether it is intelligent and only says "if the file is EXACTLY 1 hour or 2 hours [...] or 10 hours, etc. different, then I will assume it could be due to daylight savings time problems."

But for now, I am just happy with it seemingly working!

- - - Updated - - -

RickC said:

My understanding of this is that NTFS (as a journaling filesystem) uses tick counts whilst FAT systems just don't have that precision, hence stick to a 2 second median. Using the /FFT parameter apparently means 'don't be so fussy about datestamps' (to reduce file processing overhead) .However, I haven't used Robocopy for a long, long time so I could be wrong.

I can't believe I didn't make the connection between daylight savings time and this problem. It seems completely obvious!

And the 2 seconds - I didn't associate that with fact of the different file systems having different precisions of timestamps, one of which is exactly 2 seconds. Hmm... still though... I wonder why all the files would say indicate 2 seconds difference. Wouldn't one expect it sometimes to be 0 seconds wrong, sometimes 1 second wrong, and sometimes 2 seconds wrong?

Oh well, no matter for now. I am just mostly happy that you guys have offered some working solutions.

- - - Updated - - -

JLArranz said:

Executable name is "RightTime.exe" and I've been able to locate it searching exactly for that, quotes included. I've downloaded it just now to my W10 system and FC.EXE-compared it to my file, stored among my files since 2013 at least, and turned out equal. I've also run it and it seems to work, although I have just launched it, I haven't done any operation. Firefox or whatever behind it (Windows or my firewall/antivirus) asked me confirmation of the download for security reasons (a step that I've also seen with modern but unfrequently downloaded files, all legal).

According to its properties -> details page, it's from 2002 and its description is "MFC-Anwendung RightTime". I've added a "readme.txt" file with the following (I use to do this):

Anwendung RightTime is used to correct the, usually advanced or delayed one hour, modification date/time of files affected by certain defects in the management of DST, for example when recording and recovering them from external media with certain filesystems. It is a very basic program, without any intelligence to detect incorrect dates and times or select files on its own. To use it you just have to know if you have to advance or delay (one hour) the date and time of the files in a certain folder (all, subdirectories included).

Thank you so much!

I was definitely going to use this program if the robocopy switches suggested above hadn't worked for me.

I have downloaded the program and will keep it if a situation like this appears again and I can't make it work otherwise.

Thank you for all the work on checking the file! Am I understanding you correctly that you had this file from former times, and then you checked whether the executable one can download at the URL you provided was the same file as the one you had from old times?

You write something about a readme-file. I don't quite understand where to find this readme file?