Jump to content
roobieroo

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

 

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

Both are Mac OS Extended (Journaled). Both do not have ignore ownership enabled. The source drive is connected to a Mac server and the destination is connected to the computer running Retrospect.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

 

Share this post


Link to post
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.

Share this post


Link to post
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.

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×