Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by vogh

  1. Clarification to my previous comment: The USB2 drive was connected to an USB3 Hub connected directly to an USB3 port of a MacPro. Too manny cables there. And yes, the additional information seems s to be stored only when discs are not connected via USB. If you swap disks between different connections you can cheat yourself. Sorry! - The problems are nevertheless true.
  2. 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?
  3. Copying folders or disks with Retrospect 11.5 (Mac OS X 10.9.5) results in many cases in changed modification dates. With later copies these files are copied again and again whereas the originals were never changed. In addition I found that additional file info is not copied in at leas some cases. So the result is not a true clone. This is not a problem with access rights as they are identical. I enclose the information of an original file and the information of the file copied with Retrospect (different modification date, missing additional information). A similar problem existed with earlier versions of Retrospect and could be changed setting a parameter to restore modification dates in the hidden preferences (select preferences with option key). However, the relevant parameter is not there any more. Any idea how to produce a real clone with Retrospect 11?
  4. Just modify the retro_isa.ini file as proposed earlier: StartRetroISA=0 Save it and - this is now essential - make it protectd via the information menu (e.g.). The file icon will then display a small lock. Then kill the RetroISA process. It will restart, but behave like other nice processes consuming only a little bit CPU. (In case of doubt restart your Mac.) As the protection does not allow any change to the ini file StartRetroISA reamins with 0 value. Be careful: If you make changes that might effect the ini file you first must remove the protection using the info menu (or force owerwrite otherwise).
  • Create New...