Jump to content

Copy deletes entire destination every time even though files are identical


Recommended Posts

I have set up a copy script and according to the manual, selecting "overwrite entire volume" for the destination should only remove files that are not the same as on the source drive. Running the copy script again even right after it has completed erases the entire destination drive and copied everything all over again. From the manual "Retrospect saves time by not copying identical files, that is, files that share the same location, name, modification date and time, etc., that are already present on thedestination." but that is clearly not what is happening. I do have use attribute modification date when matching enabled as well.

 

What is the point of scanning the entire destination volume during the copy if it's just doing to delete the entire drive and start over from scratch? Is this a bug? How can I keep a clone without having to recopy identical files on the destination every time?

 

Retrospect 10.1.0 (221) running on Mac OS 10.8.4

 

Link to comment
Share on other sites

What is the disk format for the disks? (Mac OS Extended, FAT32, exFAT, NTFS)

 

I think it's the metadata that isn't identical. For instance, if one of the drives has "ignore ownership" checked but not the other, Retrospect will not see the files as identical.

Link to comment
Share on other sites

I've also tested this on a smaller scale with two hard drives connected to the backup machine and it still wipes all data from the destination even when run immediately following a copy operation. I also updated to Retrospect 10.2.0(201). I think it has something to do with the ACL's. If a file has an ACL, it will be deleted and copied over again. Some other files also seem to get deleted and copied again even if they don't have an ACL but I'm not sure what's special about them yet other than that it's related to the "use attribute modification date when matching" option being enabled.

Link to comment
Share on other sites

Here's what I think is going on. I'm not sure if this is specific to 10.7 and higher yet but there is a metadata attribute called kMDItemDateAdded that represents the date and time a file gets added to the filesystem. When Retrospect copies any file, instead of the file having the same kMDItemDateAdded attribute as the original, it gets updated to the time the copy happened. As a result, the file no longer is the same and gets copied all over again when the "use attribute modification date when matching" is enabled. If Retrospect would ignore the kMDItemDateAdded attribute then it would work as it should and only copy files when the ACL is changed.

 

To view the kMDItemDateAdded attribute I ran mdls testfile.txt and then compared the source and destination output in the terminal.

Link to comment
Share on other sites

Here's the reply I got from tech support.

 

Agent Response:

 

I checked with engineering and your theory about kMDItemDateAdded and it is possible it is causing some of the behavior you are seeing.  This is something we will need to investigate on our end to see if this is causing trouble and if code changes are needed.  For now, the only workaround to prevent files from being recopied is to change the preferences to not use the attribute modification date when matching.  The other option is to use Backup instead of Copy, which does not experience this type of issue.

 

Link to comment
Share on other sites

Saying to use Backup instead of Copy is all very well, except for the fact that they do two completely different things.

 

I asked on the forum about this problem ages ago, and the best suggestion I got was to stop using Retrospect Copy, and use Carbon Copy Cloner Which I did, and I haven't looked back. Costs AUD 44.95, so I guess probably about USD 40; because I'm in Australia, I only get shown an AUD price.

Link to comment
Share on other sites

Agent Response:

 

Doing some testing we do not use that attribute when the "Use attribute modification date when matching" option is turned on. We have found though that the issue you are seeing occurs because of custom ACLs and only when copying(backups do not have this problem). Just to verify are you using custom ACLs on your source data?

 

We have opened a bug for the custom ACL issue.

 

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

×
×
  • Create New...