Jump to content

Not a true copy/clone


vogh

Recommended Posts

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?

post-48528-0-34492200-1413625786_thumb.png

  • Like 1
Link to comment
Share on other sites

In the Finder's "Get Info" window, the "More Information" section (or "Weitere Informationen") is populated from a different file in OS X. You can see that the information is lost if you copy the file to a USB and use "Get Info" in a different computer.

 

Retrospect should not copy files that have not changed. Could you attach screenshots of your script? Specifically the "Summary", "Sources", "Destinations", and "Options" (Source > Macintosh) tabs.

Link to comment
Share on other sites

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?  :wacko:

post-48528-0-26046300-1413731740_thumb.png

post-48528-0-64683000-1413731741_thumb.png

post-48528-0-61403900-1413731743_thumb.png

post-48528-0-68380600-1413731745_thumb.png

post-48528-0-04213200-1413731747_thumb.png

post-48528-0-40789400-1413731748_thumb.png

post-48528-0-54648600-1413731749_thumb.png

post-48528-0-05235100-1413731751_thumb.png

post-48528-0-61779700-1413731754_thumb.png

post-48528-0-37660100-1413731759_thumb.png

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...