File date and size shouldn't become identical before contents are identical

[root]

If a file creation gets interrupted for whatever reason (USB cable unplugs, PC crashes, power outage, forced reboot, ...), subsequent comparisons by file date and size won't detect the file as out of sync? This would lead to unnoticed data loss.

FreeFileSync should make file names and dates identical *after* the contents are identical, not before.

[root]

Some files have a different file name (ending with ".ffs_tmp") while being created, but not all files. I don't know what this depends on, maybe files without a file extension (without "." in their name) are affected. Version 14.5.

[Plerry]

Assuming you have kept "fail-safe file copy" checkmarked (in Tools/Options), if FreeFileSync (FFS) intends to overwrite an existing file by a newer/different version, it retains the (pre)existing file until the process of writing the newer/different version of the file completed successfully.
In the location the newer/different version of the file is written to, temporarily two versions of the file exist until the write process of that file completes successfully; one version under the normal filename, another one with the added .ffs-tmp extension.

• If the write process completes successfully, the retained (pre)existing file is deleted, and the only file left is the newly written one, under the normal file.
• If the write process fails, an error is raised and the retained (per)existing file is restored, and the only file left is the (pre)existing one, under the normal file.
So, your "This would lead to unnoticed data loss." is not correct.

If, despite the write process completes successfully, you are afraid data might have gotten corrupted during the copy/write process, you can consider to set the VerifyCopiedFiles flag to true.

[root]

Assuming you have kept "fail-safe file copy" checkmarked (in Tools/Options)

Yes.

if FreeFileSync (FFS) intends to overwrite an existing file by a newer/different version

No, I mean *creating* a file that didn't exist on the right. I clicked "Pause", FFS says "Creating file ...", but that destination file already had its final file name, size, and date.

Maybe when I click "Pause", FFS still finishes copying and renaming the current file? I thought that FFS paused at 80% of that file, but maybe I misunderstood that. I looked again and can't find a percentage for that file in the UI, only a percentage for all files.

Thanks!

[xCSxXenon]

"Pause" is a 'soft' command. It actually pauses once the current action is completed.

[root]

Now I know what the bug is. When creating a *large* file, FFS does show the percentage for that file. "Pause" freezes the displayed per-file and total percentage, which is misleading because the file creation continues.

The worst part is that this makes FFS seem unreliable, as I described: The UI says that the file creation is paused at some intermediate percentage, but the file already has its final name and size. So it seems like an incomplete file will be missed during future comparisons.

So please show the correct per-file and total percentages after pausing. While the percentages are still growing after clicking "Pause", the message "Pausing..." can blink/appear right after the percentages. When the file is complete, write "Finished creating" instead of "Creating".

Version 14.5.

[Plerry]

if FreeFileSync (FFS) intends to overwrite an existing file by a newer/different version

No, I mean *creating* a file that didn't exist on the right. I clicked "Pause", FFS says "Creating file ...", but that destination file already had its final file name, size, and date.

For such files there is no need (or even the possibility) to temporarily retain the (pre)existing version in the write location, so you don't (temporarily) get an .ffs-tmp version.
But fortunately, meanwhile it is clear that raising the .ffs-temp question sort of hided your actual question .

[root]

@Plerry As far as I know, "Fail-safe file copy" uses ".ffs_tmp" even if a file is being newly created (without overwriting a pre-existing version). Otherwise an incomplete file would have the final filename.