date compare fails

[turnkit]

Using Mac OS version with NTFS drive mounted (Paragon) and several files on the source show up with date modified date as Dec 31, 1969 7:00 PM.

I am copying from the Mac over to a Synology NAS. The copied (destination) file shows the time and date at the time of the copy for modification date.

Unfortunately whenever I run a COMPARE these files with the pre-epoch date and time will always fail comparison.

If time and dates likes Dec 31, 1969 7:00 PM cannot be properly cloned (copied) could an option be added so that the size + time and date comparisons will skip the time and date comparison whenever the source is Dec 31, 1969?

Without an option there is no easy way to determine if there was a copy issue.

Ideally though the dates would match when the copy was done.

[Plerry]

A simple search learns that date/time Dec 31, 1969 7:00 PM is reported for files with a corrupt date/time code, as Unix date/time 00:00:00 UTC, for Unix the dawn of time, corresponds to Jan 1, 1970.
So, don't be too surprised if FFS can not handle that.
Maybe you can do a find for those files and change the date/time-code into something valid.

[Zenju]

Something's strange: FFS only treats file times less than Jan 1 1970 00:00:00 UTC as invalid(*). So if "Dec 31, 1969 7:00 PM" local time were equal to Jan 1 1970 00:00:00 UTC = time_t(0), there shouldn't be a "File %x has an invalid date" conflict.

*) File time of exactly "Jan 1 1970 00:00:00 UTC" usually means "no date info available", which is not an error.

Moreover: Conflict items are synced correctly in "mirror" mode, and only need manual intervention when using "two way".