Comparison by file time only

[maykelbembibre]

If it happens that the left file has the same modification date as the right file but a different size, I see it as a byte corruption case. Because if it hasn't been modified as its date says, why does it have different contents? This program assigns by default the action of updating the right item to these cases. If it were a corruption case, the corruption would be propagated to the right side. For this reason, I think the comparison settings should have a new option "File time" that only compares files by their modification date. This way, I can make sure that all updates to the right side are from files I've definitely modified deliberately.

Or, this could be solved by just comparing by file time and size but the cases where dates are identical but size different could have their action default to conflict for manual resolution instead of overwriting the right file by default. That way, if this strange case ever happens, the user has the final say about what to do.

Thank you very much.

[favoredrive]

What about cases where it is done on purpose like exiftool -preserve?
You should not rely on file synchronization for data integrity or backups. Use the right tools with checksums.

[maykelbembibre]

If FreeFileSync included a setting to do this, people in your case could set it to compare date and size and people in my case could set it to compare date only. The setting that is good for you depends on your specific case.

I rely on FreeFileSync for backups from my primary storage medium to my secondary medium. I've tried a thousand tools and this one is by far the one that I've found the easiest to use and the most reliable. Having logs for everything, versioning, and recycle bin for overwrites and deletions, FreeFileSync makes my backup strategy quite robust.

[favoredrive]

Data corruption can occur with identical file size so relying on file size/time is not good enough:
https://en.wikipedia.org/wiki/Data_degradation#Mitigation

the easiest to use and the most reliable

I wouldn't go by how easy it is when it comes to important data. Most reliable compared to what?

FreeFileSync makes my backup strategy quite robust

How do you even know that your "backup" actually contains the original data?

[xCSxXenon]

This is really only a problem if you are automating FFS or not checking the comparison results. FFS isn't a corruption finder, it's a sync tool. Proper backup strategy basically eliminates the hypothetical situation you described. If you use versioning and have it retain 3 versions, there would have to be 4 corruption events that get synced, which is extremely low chance without you noticing and intervening before.

[maykelbembibre]

Data corruption can occur with identical file size so relying on file size/time is not good enough:
https://en.wikipedia.org/wiki/Data_degradation#Mitigation

the easiest to use and the most reliable

I wouldn't go by how easy it is when it comes to important data. Most reliable compared to what?

FreeFileSync makes my backup strategy quite robust

How do you even know that your "backup" actually contains the original data?

It makes sense that data corruption can occur both with identical file size or changed file size. If the file size changes as a result of corruption and we only compare by modification date, the corruption won't be propagated. If the file size doesn't change, the corruption won't be propagated either. My point is: how likely is it that a file corrupts because of silent bit rot or something like that and its modification date magically changes to a newer valid date? That's what makes me think comparing only by modification date is robust. Only when I've intentionally modified a file will it be propagated to the right side.

What I mean with robust and reliable is that in the past I used to back up everything from my primary storage medium to my secondary one manually, it was painstaking, I had to copy everything, replace what already existed and it was very clumsy. With FreeFileSync I get automation, removing human errors, I get to decide what gets replaced and what doesn't, just by tweaking the sync settings, I automatically get a log of every file that was replaced, I get versioning, I get a recycle bin not only for deletions but for replacements, which manual backups don't have. So, I quite like my backup setup with FreeFileSync.

[favoredrive]

But you will never know if your backup data is not corrupted. You should at least compare by file content once in a while.
I see why you are happy. I used it this way for years, but at some point I took the next step to a proper backup solution (kopia/restic). I can recommend KopiaUI or Backrest if do not like working in the terminal.

[therube]

if the left file has the same modification date as the right file but a different size, I see it as a byte corruption case

Why would you assume that, byte corruption.
Actually compare the files & see if you can see what the difference is between them.

Maybe it is simply an additional nul (or $20$) character appended to the end of the file.

If it's more then a 1-byte difference, maybe it is an internal "tag" in the file that has been modified. Maybe not by you, but by big brother (Windows) adding meta-data to the file (or whatever).

Maybe it is malware, & the file contain a "you've been hacked, call 1-800-fix-meee to retrieve your data" string within.

[maykelbembibre]

But you will never know if your backup data is not corrupted. You should at least compare by file content once in a while.
I see why you are happy. I used it this way for years, but at some point I took the next step to a proper backup solution (kopia/restic). I can recommend KopiaUI or Backrest if do not like working in the terminal.

Thanks for the suggestions. I'll keep them in mind for the future. But I am a newbie when it comes to data hoarding, so I'll need some time to make up my mind to use such sophisticated tools. I've never had evidence of byte corruption happening to my content. But if someday I found a file that doesn't open well, at least I could compare it to my backup medium and recover the good one (supposing the corruption hasn't been propagated by previous syncs, but that's not likely, because I only sync file changes that I've purposefully modified).

[maykelbembibre]

if the left file has the same modification date as the right file but a different size, I see it as a byte corruption case

Why would you assume that, byte corruption.
Actually compare the files & see if you can see what the difference is between them.

Maybe it is simply an additional nul (or $20$) character appended to the end of the file.

If it's more then a 1-byte difference, maybe it is an internal "tag" in the file that has been modified. Maybe not by you, but by big brother (Windows) adding meta-data to the file (or whatever).

Maybe it is malware, & the file contain a "you've been hacked, call 1-800-fix-meee to retrieve your data" string within.

Because the nul and internal tag cases have never happened to me in 21 years using computers, so, although they are theoretically plausible, I can hazard a guess that their likelihood is rather on the small side.
And if the hacker case happened, of course I wouldn't want to propagate the change to the backup lol! I would be quite screwed if that ever happened to me...

[therube]

if the left file has the same modification date as the right file but a different size, I see it as a byte corruption case

This is something you have actually seen, & not just theoretical?

[maykelbembibre]

if the left file has the same modification date as the right file but a different size, I see it as a byte corruption case

This is something you have actually seen, & not just theoretical?

It's pure theory, but seeing as most programs update the modification date when modifying a file and it is the most expected thing to happen, if a file on the left has exactly the same modification date as its mirror file on the right side but it has a different size, I'd be extremely suspicious. I mean, as far as I have used computers all my life, I have never had a case where I wanted to modify a file and not update its modification date. In fact, I think this is useful, as it allows you to compare files and see which are older or newer.

[therube]

I'd be suspicious too.

If a file has a different size, left vs. right, it cannot be identical, so date at that point is relatively irrelevant.

And, it would prompt me to say, "hey, why are the file sizes different"?
And, given that date is identical, it would further make me ask, "heh, why are the file sizes different, & yet the dates are identical - which is (potentially) mighty weird"?

And at that point, I'd throw the 2 files to a binary comparison program & see what that says.


Also note that malware (depending on what its intentions are) is apt to physically change the file, leaving the size & date the same (thereby hiding the fact that it did make changes to the file).