I have some follow-up questions about Mirror backups, prompted by the answers provided in Admin's post above.
1. If a source file's "read-only" or "archived" or "hidden" or "system" attribute bit has changed but its "date modified" and "date created" have not changed, does FBackup overwrite the destination copy or does it simply change the corresponding attribute bit(s) of the destination copy? (The latter would be faster.) If the former, why not the latter?
2. Admin's 2nd answer above implies FBackup will detect change of a source file's content even when none of the source file's attributes (such as "date modified") have changed. How does FBackup determine that the source file's content has changed?
3. What info is stored in the catalog file and how is it used? None of the comparison criteria listed above by Admin--date modified, date created, read-only, archived, hidden and system--require storage in a catalog file because they can be read directly from Windows' file system. (One reason I'm asking about the catalog file is that FBackup will unnecessarily overwrite all destination files--which takes many hours--if the catalog doesn't exist or if the user modifies some properties of the backup job such as the destination folder. Another reason is that if the catalog file contains a hash value for each destination file, FBackup could use the hash values as described in question #5 below.)
4. Admin's list of comparison criteria (see above) does not include "file contents" or "filename," which means Admin's 2nd and 3rd answers (see above) appear inconsistent with Admin's list of comparison criteria. Is the list incomplete? If so, what is the complete list of comparison criteria that FBackup uses to determine when a file needs to be re-copied to the mirror destination?
5. Admin wrote above that the reason FBackup cannot simply rename or move a destination file to match a renamed or moved source file is because FBackup does not track "renaming" or "moving" actions. Can't it be done without tracking such actions? Here is a way it can be done, which assumes only that the catalog file maintains a hash value for each destination file: Suppose, for example, that the user renamed a source file. During the mirror operation, FBackup can see the corresponding destination file with the old filename, which tentatively appears to no longer exist in the source, and FBackup can see the source file, which tentatively appears not to exist yet in the destination. If the pair of files have the same size, FBackup can compare their hash values to determine whether their contents are the same, and if their contents are the same then the destination file can simply be renamed (instead of deleted and backing up the source file again). So, at the beginning of the mirror operation--before copying or deleting any files--FBackup would construct a list of source files that tentatively appear not to exist yet in the destination, and a list of destination files that tentatively appear to no longer exist in the source. These two lists can be quickly sorted by filesize, and FBackup can compare the hash values of all pairs of same-size files to determine whether their contents are the same. When identical, the pair of files would be removed from the lists and the destination file would be renamed or moved to match the name and location of the source file. For efficiency, only files larger than some threshold would need to be compared. (The optimal size threshold should be based on the speed of the relevant disk access operations.)
6. If the user modifies or deletes a destination file, will FBackup detect that during the mirror operation, or will FBackup incorrectly assume the catalog file's data about the destination files is still correct?