Thank you for your immediate reply. Regarding "More information" if I may: Using other tools like e. g. CarbonCopyConer this information exists even on external USB clones. Sometimes this information is essential to know that you copy exactly the file back when you experience problems. This means I should not use Retrospect to clone my disks? Retrospect does copy files that have not changed and have the right access rights and ignore ownership is not enabled on the disks. I experience similar problems as discussed in the following link: http://forums.retrospect.com/index.php?/topic/150830-clone-script-copies-lots-of-data-even-immediately-after-finishing-cloning/ (Maybe I should mention that I have "use attribute modification date when matching" enabled as I thought this should be useful, in contrast to the case described in the link.) Coming back to my original question/problem: I just made some experiments. I tried to prepare a "Test" folder with a few files that were copied before with chained modification date and copied them with Retrospect 11.5.1 (104). As usual with such experiments: No problems! - some result with "use attribute modification date when matching" enabled and disabled. So I started one of my weekly copies (from internal SSD to external USB2 disk via Thunderbolt, same connection and disk as used in the previous experiment without any problems). And again unchanged files were copied an received new modification dates (today's date and presumably the time when copied). Funny: Even the Retrospect dmg files received new modification dates. I took several files that received new modification dates, copied them to my "Test" folder mentioned above - and Retrospect copies them neatly to the "Test" folder on the USB2 disk (even with different access rights for the folders). So there must be some more subtle "environmental" or "history" problem with the full copy. Then I copied one of the existing folders from the SSD to the USB2 disk using Retrospect. As you might have expected: everything looks good! Difference: For my weekly copies I use a custom script or rule ("Regel" in the German version). For the experiments I used "All files". I enclose screenshots (files 1 through 10, 1 and 2 concatenated to avoid more than 10 files) of what you requested. Looking at the rule or script ("Regel" in German) be aware that I tried (by trial and error, not by logical thinking) to find a rule that does what I want in contrast to a logical rule that I thought should do what I wanted but did not succeed. I also enclose an example of a folder with many modification dates of today (19. Oktober 2014). I should mention that comparing this with previous copies to other disks the modification does not always happen to the same files. Even in the example there is probably no obvious reason why some VueScan updates (vuex64...) get changed others not. Finally, it seems that copies before and possibly around July 20, 2014 were OK. (I usually use the latest version of Retrospect within one or two weeks after availability, but I am not sure which version I used then.) Strange?