> Retrospect uses several matching criteria to compare files
> that have already been backed up to what is about to be backed
> up. If one of the following has been changed at all,
> Retrospect will back up the file again:
> MAC files:
> name, size, type, creator, creation date and time,
> modify date and time, and label.
> PC files:
> name, size, modify date and time, file system.
Have you ever consider using something even more accurate as the
criterion--say, CRC32, or some sort of file signature? Will it
slow down Retrospect significantly than the current approach?
I'm asking because I've found many different applications put
same version of system files (dll and such) with different
date/time. The file name, size and version no. (by checking the
file's properties) stay the same, and a binary comparison would
show the two files are identical. They have touched the
date/time probably because they want all their files to have the
same date/time, or because the original software development
package (MS C++, Delphi, etc.) did so. And some other software
would make the date/time of its installation the date/time of
all the files it put in, regardless their original date/time.
Under current design, Retrospect would back those files up
again. By way of CRC32 check, Retrospect would find those files
are indeed identical to the original ones and skip them. It
would not only save storage space, but also give me extra
confidence for whenever I catch some new application overwriting
my system files, I can look in Retrospect's backup preview
window and find which of them are in fact identical (hence no
worry) and which are different (so I might have to restore my
backed up version to see which one is in fact newer).
I don't know if any application would change a file's content
without changing its date/time and size. But if that happens, a
CRC32 check would expose them, too.
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]