How to know why backup file is "updated?"

[az99]

After a "compare" on date/time, I mouse over the green arrows down the center of the screen. Some say "item on left is newer" (something like that.) But, sometimes all it says is "update [filename]." It doesn't say *why* it's being updated (what's different?). When I run the compare again on file content, those update rows disappear.

I'm assuming it's a difference in atime? Whatever it is, it would be helpful of there was always an explanation of why the update is occurring.

The reason this topic came to mind is that I backed up a /home/user/documents folder. Then installed a new distro, and copied that folder back. My first backup of that needed to update *all* the files even though the file content didn't change. (That's when I noticed all the "update [filename]" green arrows which didn't say why it's updating.).

Apparently I need to learn how to copy without updating the atime. (Or, use "noatime" in my fstab.). But, this got me to wondering why FreeFileSynch can't detect that the only thing that's different is atime, and merely update that value (instead of copying 14 gig of data gain)? For example: what if FreeFileSync let me choose *both* date/time AND file content, and could determine that the only thing that changed is atime, and the file content doesn't need to be copied?

I think that would be a useful feature to get an existing backup "realigned" (so to speak) without an hour of backing up files that don't really need it.

Maybe there's a script I could run to set matching file names to the same atime. I googled and couldn't find anything like that. It would be nice feature if FreeFileSynch could do that somehow. (Again, I'm assuming the atime is the reason all these files needed backup. That assumption gets back to how it would be nice if the green arrow always gave a reason why the update is happening.).

[Zenju]

FFS doesn't use atime. That said it seems you've hovered over the sync direction column. There isn't any additional info on why it's updated because the reason is always the same: the selected sync variant.
But it seems this isn't what you're interested in anyway: You want to know why FFS is categorizing files as different: This is shown in the left one of the two middle columns.

[az99]

@Zenju, thank you. When I can recreate this, I'll come back with more info. I don't know what else could be causing what I saw. The modify times and file sizes were the same (when viewed with file manager->properties). It seemed the only thing that could be different was the access time.

I'll return to this thread when I have a better example. I've used FFS for years, and have seen this before. It shouldn't take too long.