Messed up timestamps

[woody]

I have two external hard drives that are used for storage and contain the same files. I recently noticed that the timestamps of a large portion of the files in one of the drives (about in the 30% of all files) are completely wrong as the actual "Creation" dates have been replaced with dates of 2026 and 2027.

The files on both drives are updated with FreeFileSync 10.10 therefore I suspect that it probably has something to do with it. Has anybody else had this problem?

[therube]

Anything "odd" with the source file dates, like maybe prior to 1-1-1970 ?

If you copy one of the source files that ended up with a wrong date, & then sync that file (with FFS) to your external HDD, does the external HDD then show a wrong date?

[woody]

Thanks for your reply therube.

No, nothing odd with the source file dates, they all have normal dates from 2018/19.

I did what you suggested: I copied several of the source files that ended up with a wrong date and then synced them using FFS to the external HDD. The "Creation" dates are correct (today) and the "Modification" are also correct (same as in the source files). So looks like it works fine.
Could it have something to do with the health of the particular external HDD or something?

[therube]

Do a content (or hash) check of some of your source files against some of your date changed files & see if the files are identical.

[woody]

I did a Content check between the two HDD's and all files between them are identical. The File Time and Size check however finds 1.940 files that are different because their timstamps have somehow been changed with dates from 2026/2017.

[woody]

Any other ideas on what might have caused this problem?

[xCSxXenon]

Does the same thing happen with other folders?

[woody]

Does the same thing happen with other folders?

No, only with the said ones.

[JDB]

Hi, Any software that modifies dates/times would be suspect. Do you recall over the history of those files, ever mounting the volume or accessing the files with an older OS, poorly built version of Samba, an exotic Linux VM, etc?

Some utilities such as BeyondCompare and FolderTimeUpdate can also tweak the timestamps (hopefully under your careful direction! ... but typo errors can happen :-) )

Often, software developers who develop subscription based software will exercise their "time bomb" mechanism by setting the system date into the future when they run tests. If you ever ran any "beta" or Trial software that used such a mechanism, perhaps that was a culprit.

One final anomaly: If you use NTP or "Windows Time" to automatically update your system clock periodically, it's possible that one of the servers in your list was corrupt, and during the time that those files were created, your system actually had a bogus date. You should only use servers listed here: http://support.ntp.org/bin/view/Servers/WebHome

I can't say that any of the above affected you, but it casts reasonable doubt on the integrity of date stamps.

[woody]

Thanks for your reply JDB.

The only thing that seems relevant in my case is that the particular hard drive was often connected to an older PC that runs Win XP (SP2, authentic). That PC functions normally though.

[JDB]

Woody,

Perhaps one time, after the files were updated, the drive was removed from the XP system without using "Safe Removal".

Is the File System NTFS? I wonder if it used to be FAT32, and you used an old version of the Microsoft "CONVERT" command to convert from FAT32 to NTFS, and there were some unnoticed errors that were later automatically "repaired" (i.e. broken), by some background task like Norton Utilities or 360 (or similar).

These utilities often hide error messages from the user because they want customers to (erroneously) believe that they are so easy to use, and fix everything behind the curtains automatically as if by magic. For example, you have to dig deep in the Windows Event Log or Task Scheduler to find out the last time that "defrag" was run! And typically, the Event Log often contains hundreds of critical disk I/O (and other) critical errors you never knew occurred.

-JDB

[woody]

Well, I've never tried to convert the file system of that drive; I think it has always been FAT32.

As for the possibility of the hard drive being removed from the computer without using "Safe Removal", I don't think it has ever happened either, but perhaps at some point the USB connector of the drive could have been instantly disconnected from the system because I had noticed that sometimes I had trouble with connecting it properly. I always take care to be sure that it is connected properly connected before proceed to using though, so that's only a speculation.

Let me know what you think. Thank you.

[JDB]

Hi again Woody,

Perhaps there was a glitch as you described.
Since it would be almost impossible to reproduce an error like this, it's all speculation.

Do you know for sure that your problem ONLY affected the date/time stamps? Or could there be errors in actual file content data? A problem affecting only the dates would indicate something of a logical origin, like an OS or software bug, or "unsafe removal"; whereas random corruption throughout a file would more likely be hardware related, such as the USB chip implementation.

I don't trust the Etron USB 3.0 chip on my computer's motherboard, because I have verified some backups in the past, and found single-bit errors in random locations in huge files written to drives in several different external USB enclosures. Presumably, the USB chip was under heavy load during a backup. I was able to reproduce the error, and found that increasing Parallel File Operations in the FFS comparison settings seemed to make the problem worse, but not consistently.

I like Renesas/NEC 720201/720202 USB chips, so I added a PCI-E card to my system with that chip, and run all backups through its ports now, with no errors (so far!), even with parallel file operations increased.

Likewise, some external HDD controllers may have similar issues with their "bridge" chips. And they never advertise which chip architecture they use. For sure, the enclosure manufacturer is going to select the cheapest possible one, to improve their sales margins. I have one enclosure with an ASMedia ASMT2115 USB-SATA bridge chip, and it is horrendously slow. Perhaps they slowed it down to prevent buffer overruns.

-JDB

[woody]

Thank you for your reply JDB.

Do you know for sure that your problem ONLY affected the date/time stamps? Or could there be errors in actual file content data? A problem affecting only the dates would indicate something of a logical origin, like an OS or software bug, or "unsafe removal"; whereas random corruption throughout a file would more likely be hardware related, such as the USB chip implementation.

As therube suggested above, I also did a content check between the two HDD's and all files between them were identical, so I think I can say for sure that the problem only affected the date/time stamps.
If it helps at all, the external HDD with the problematic files is an old Freecom 2.5" 80GB and was connected to a computer that runs Win XP and I pretty much use only for backups.

[JDB]

In conclusion, I think that given the amount of time the Freecom drive has been in service, there was plenty of opportunity for some undetected event to cause the problem. I am 80% confident it was an unsafe removal; 10% confident that some buggy utility wrangled the metadata, and 10% confident that a cosmic ray struck right in the middle of the controller chip at the exact moment of an update. Also given the amount of time it has been in service, perhaps it's time to upgrade to another: https://www.newegg.com/model-wdbuzg0010bbk-wesn-1tb/p/1E8-0006-00100?Description=external+hdd (just an example of something that sells for way less than $100)

[xCSxXenon]

It may be worth copying that folder to a temp location manually, then delete the source copy, then recopy the data from that temp location to the source, then try the syncing again. Keep track of timestamps during this manual process. I don't know how deep you want to go into diagnosing the issue, but that's what I would do next. This will recreate the folder on the source

[woody]

Thanks for your opinion JDB. I plan to upgrade to a new HDD like the WD one you mentioned. Perhaps that old Freecom drive has some mild connectivity problem which was the cause of this phenomenon.

Also, thanks for the idea xCSxXenon.