Copied folders lose their modification date

[amkassir]

When copying from one disk image to a second, blank one, the modification date of all folders is changed to the present date and time of the operation.

Source disk image: Mac OS extended (journaled), encrypted 256-bit

Destination disk image: Mac OS extended (journaled) OR APFS, encrypted 256-bit

Any idea why this might be happening?

Retrospect 18.0.0 with macOS Big Sur 11.4

[Nigel Smith]

Give the just-released 18.1.0.113 a try -- not all fixes are listed in the release notes.

[Mayoff]

>Source disk image

When you see disk image, are you talking about .dmg files or do you mean the actual mounted disk?

Are you using a backup script or a copy media set script? 

Maybe consider posting a screenshot of what you are seeing. You may also want to just contact support directly and we can try to help. 

[DavidHertzberg]

amkassir,

I think the head of Retrospect Tech Support may—in his post directly above—have meant to ask "Are you using a Backup script or a Copy non-media-set [my change from "copy media set"] script?".  (IMHO the change from Duplicate to Copy was the only mistake made by the Tyrannical Terminologist—my tag for someone whose name I've never been told—for Retrospect Mac 8.  Not making that change would have avoided much confusion for Retrospect Mac users between Copy Media Set and Copy Backup and Copy, which doesn't exist for Retrospect Windows users—whose Copy is named Duplicate.)

The reason I say that is this paragraph on page 109 of the Retrospect Mac 18 User's Guide:

Quote

Set source (volume’s/folders’/files’) backup time:These options, not available with copy operations [my emphasis], record a backup time for each source volume, folder, or file. (The MacOS keeps track of the creation date, modification date, and backup date for each file, folder, and volume.) Using these options allows you to create Rules based on the “backup time,” which is the moment execution begins. Retrospect cannot set the source backup time on a client computer if its Retrospect Client control panel has been set to allow read access only. By default, the volume option is on and files and folders options are off [my emphasis].

It sounds to me as if either [1] you are using a Backup script and the files and folders options have somehow been turned on or [2] you are using a Copy script—for which the options shouldn't be applicable per the UG quote.  Either alternative may show a bug in Retrospect Mac 18.0; I notice "Duplicate [the Retrospect Windows term]: Fixed issue where process can overwrite destination even if newer than source (#9260)" in the cumulative Release Notes for 18.0 and suspect a foul-up.  If there was a foul-up, it may have been fixed in 18.1; per Nigel Smith up-thread, "not all fixes are listed in the release notes."

[amkassir]

Thank you for all the replies. I was using a Copy script (not Copy Media Set or Copy Backup) to copy the contents of an actually mounted disk image to another (initially empty) mounted disk image. Based on the posts above, this might be a bug in Retrospect. I haven't yet tried this operation using the newer version of Retrospect. 

After my post, I tried the same operation with the destination being just a folder on my Mac's internal SSD, rather than residing on a disk image. The same problem occurred. I ended up having to use Carbon Copy Cloner to copy the items.

[Nigel Smith]

Try the newest version of Retrospect. If you can, try v17 as well, on that same machine. The more relevant information you can send to Mayoff & team the better (your star sign probably isn't important at this point 🙂 )! You could also try a simple Finder Copy between the two images, just to check that works as expected.

Certainly a Copy script should maintain the copied files' metadata, and it does on my tests with macOS 10.15.7, RSv17, and mounted encrypted disk images. But there's always a chance that something's been changed on the OS side, and it's just that you're seeing the effects in RS...