Original modified date for macOS files with com.apple.ResourceFork

Support
#1

Hi,

I currently use Arq and am looking at additional tools to complement the current backup strategy. One key requirement for me is preservation of all file attributes from macOS, especially the various dates on a file on macOS.

I’m currently trialing Duplicacy on macOS (Mojave). One of my tests uses a subset of my data that has extended attributes and resource forks. I’ve noticed that on restore, the “Date Modified” is set to today’s date when the file has a resource fork (com.apple.ResourceFork). This does not happen with Arq. If I remove the resource fork from the file and restore, the original Date Modified date is preserved.

Couple of quick questions:

  • Is this a known constraint in Duplicacy and does anyone know if there’s any plan to look into this current behavior?

  • I’ve tried searching and haven’t found a direct hit yet, but does anyone know of any posts that touch upon Duplicacy’s coverage with respect to preservation of file attributes (extended/resource forks, etc.)?

Many thanks.

#2

Extended attributes are backed up and restored by default. Resource forks are not specifically handled, but since they are actually implemented as a special extended attribute (com.apple.ResourceFork) they are backed up and restored as well.

When restoring a file, the extended attributes are restored after the modified time. That may explain why the modified time isn’t restored correctly. However, in my tests changing the extended attributes doesn’t change the modified time, so I’m not sure if the order matters.

#3

Thanks. For what it’s worth, my simple test used a copy of a file with a resource fork as well as additional extended attributes. I removed the resource fork from the copy (but kept the additional extended attributes).

Restoring both files results in different modified dates for each file; the one without resource fork maintained the original date; the one with the resource fork had the restore date as the modified date.

These tests were done with Mac local storage and sftp to a Linux-based NAS. Both storage locations had the same result on restore.

So I would tend to agree with you that, if resource forks are not handled in a specific way, but as an extended attribute, then the order of restore is not necessarily the factor here (since without results in correct modified date). Something seems to be happening when com.apple.ResourceFork is present, though.