The only slightly weird thing about the files is they
have dates from 1980
I was actually thinking this might be the case before I even got
to this sentence. It sounds like your files have a corrupted
modification date, or perhaps some other kind of corruption to
their filesystem entries. It is interesting that other files have
the similar issue but aren't getting recopied. I wonder if CCC's
log might have some insight, I actually make a log entry if a file
has a truncated modification date.
Can you submit your logs to me for review? The easiest way to do
this is from within CCC:
Choose "Report a problem" from the Help menu
Click on the "Submit Logs" tab and review the information
Click on the "Submit Logs" button
Update this discussion to let us know that you've submitted
your logs, and please note the submission ID at the bottom of the
Submit Logs tab.
Assuming that the problem is a matter of a corrupted
modification date, I wonder if dropping the files (from the source)
onto the attached application might resolve the problem. This
application will reset the modification date and creation date to
the current time.
it doesn't seem to work, I just get: sh:
/usr/binSetFile: No such file or directory
Ah, I forgot that I add that tool to all of my test systems (I
use it as part of my auditing and QA procedures). Try the attached
version instead, it has that tool in its bundle.
I found some sites that tell me how to modify the
creation date using terminal which I did for one file, however
Carbon Copy still seems to copy this file even though it has a
I would expect that to happen for the first backup after you
reset the date because the file on the destination still has a
different modification date -- newer or older doesn't matter. Let
me know whether the second backup task that you run after resetting
the dates on these items continues to copy them.