Add "dirty" volume check before syncing?

[MartinPC]

@zenju:

I have a friend who uses FreeFileSÿnc to automatically synchronize data files on his two home computers, using RealTimeSync tasks. He recently suffered a power outage and the UPS for one of his computers failed. As a result, the computer in question was powered off without an orderly Windows shutdown.

He started Windows normally (with networking enabled), but not long after logging in got a BSOD warning him that the system was corrupted. He restarted in safe mode without networking, ran a system file check (sfc.exe /scannow from an Administrator command prompt), scheduled a diskcheck, and restarted. The system file check showed no integrity violations; I don't think he caught the results of the diskcheck. He logged in normally and again got a BSOD not long after.

At this point, he swapped in a cloned system drive he had made three weeks earlier, and his computer started and ran normally.

Unfortunately, he soon discovered that many of his data files were missing, including ones that predated the time the cloned system drive was made. He was forced to search for the most recent FFS backups of each file and "restore" them, a process that took him many, many hours.

My tentative theory is that the uncontrolled shutdown irreparably corrupted the index entries for the missing files but left FFS's databases on the computer intact. Windows and FFS thought the files had been deleted, so each time he logged in normally, with networking, his RealTimeSync tasks (hosted on the other computer) automatically ran and dutifully replicated the "new, more recent" deletions.

No syncing utility can distinguish between intentionally deleted files and accidentally deleted files, but I wonder whether situations like my friend's could be avoided, at least to some degree, if FFS/RTS included a check for volumes flagged as "dirty" and refused to run until the volume was "clean." I know nothing about Macs and very little about Linux, but I suspect they must have similar flags to indicate that the file system is suspected of being corrupted.

Anyway, my point is that FFS/RTS should refuse to run when at least one of the volumes it targets is flagged as "dirty." (And if that's already the case, then my theory as to what happened is wrong!)

All the best, zenju. I really appreciate the ongoing improvements to FFS, especially the age and number caps for backups introduced with (?) version 10.4.