Jump to content

Why does duplication always erase all files first?


Recommended Posts

Everytime I run a duplication script on retrospect express (Mac), it erases all the files first, then copies all the files over again. I thought it was not supposed to erase a file that is identical to the original. I have tried "replace entire disk" and "replace corresponding files". How can I get it to only delete and replace files that have changed?

Thanks for any help.

Link to comment
Share on other sites

I cannot figure out why Retrospect does not see the files as identical.

Ask Retrospect to show you.

 

Immediate->Duplicate->Files Chosen (button)

 

Will show information for Source, Destination and Copying.

Does "Copying" show Already copied at 0% and Need to copy at 100%?

 

In the Browser window, select one file from the list (this is the Source) and press Command+I (or Get Info from the File Menu)

 

Now visit

Configure->Volumes->Destination_Volume_Used_In_Duplicate->Browse

 

Find the same file, and select it and Get Info on it.

 

Move the two Get Info windows side by side, and compare. Anything different?

 

This method does not show extended attributes, as that feature was added to Retrospect later, without the get info dialog box being updated. In that case, you might want to disable the Use attribute modification date when matching option from your Duplicate operation.

Link to comment
Share on other sites

  • 5 months later...

I have the _EXACT_ same problem as the topicstarter. Also on the Mac. Using 6.1.138

 

When I use duplicate the first time it nicely copies everything. When I do it again, it just copies everyting again.

 

The files are identical, the hard drives both are Mac OS Extended (Journaled).

 

So I'm wondering why Retrospect is copying everything everytime. We're using Retrospect for some time now, but if this isn't working, I'm really have to change the software package. I don't want to tho, because everything else works really great in Retrospect.

 

How can I duplicate without Retrospect deleting all the files and copying everything everytime?

Link to comment
Share on other sites

I have the _EXACT_ same problem as the topicstarter. Also on the Mac. Using 6.1.138

Your version of Retrospect 6.1 is very out of date, and the update to 6.1.230 (the current version) is free. Whatever. This may not be your problem.

 

When I use duplicate the first time it nicely copies everything. When I do it again, it just copies everyting again.

 

The files are identical, the hard drives both are Mac OS Extended (Journaled).

 

So I'm wondering why Retrospect is copying everything everytime. We're using Retrospect for some time now, but if this isn't working, I'm really have to change the software package. I don't want to tho, because everything else works really great in Retrospect.

 

How can I duplicate without Retrospect deleting all the files and copying everything everytime?

I bet that you have the destination options set to "Replace entire disk" or some such rather than "Replace corresponding files".

 

Please post a screenshot of your "Duplicate > Destination" dialog window.

 

Russ

Link to comment
Share on other sites

I bet that you have the destination options set to "Replace entire disk" or some such rather than "Replace corresponding files".

Actually, during a Duplicate, this setting, variously called "Replace entire disk" and "Replace entire contents" should still only replace those files that have changed since the last duplicate.

 

The observed phenomenon suggests that some file attribute has changed, at least in Retrospect's eyes, since the previous duplicate.

Link to comment
Share on other sites

  • 4 months later...

I am also experiencing the exact same issue. We have an XServe G5 running OS X 10.4.11 and Retrospect 6.1.230.

 

As a test I'd duplicate a 600MB/4000file folder from the XRaid to a LaCie 4Big.

 

In accordance with the Retrospect manual, the contents of the 4Big are wiped, and then the test folder is duplicated using the "Replace Entire Disk" option. So far, so good.

 

I'd immediately run the same script again. According to the documentation, "identical files already present on the destination are not duplicated." Status windows will show Restrospect scanning the files and privileges of the source, then the files and privileges of the destination. The Duplicate progress window will appear. So far, expected behavior.

 

And then another status window appears saying "Deleting" as it deletes all the files on the destination. That is not expected per the Retrospect manual. The operation proceeds, copying over the same (unchanged) files it copied before.

 

When it finishes I used "Get Info" on one file from both the source and destination. The file size, name and creation date are identical. However, the modification date does not match - it shows the date the duplicate file was written to the destination (as expected).

 

Apparently this modification date difference is what's throwing off Retrospect. One would expect the "Duplicate" function to only copy those source files with a newer modification date, but that doesn't appear to be the case.

 

If one disables the "Use attribute modification date when matching" (found under Options, More Choices, Matching), then the Duplicate function behaves as everyone expects - any changes to the source (rename, modify, move, delete) are reflected on the destination, with unchanged files remaining untouched.

 

Unfortunately, this option is not described in the Retrospect manual. Selecting it seems counter-intuitive - one would expect that by not looking at the modification date, files that are modified would get overlooked in subsequent Duplication runs.

 

However, my testing shows that is not the case. Turning off this option finally got the Duplicate function to behave as most people would expect.

Link to comment
Share on other sites

IWhen it finishes I used "Get Info" on one file from both the source and destination. The file size, name and creation date are identical. However, the modification date does not match - it shows the date the duplicate file was written to the destination (as expected).

That is NOT expected. You will see that for folders, but the dates should be preserved for files.

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...