macOS restore: original modified date not preserved on files with com.apple.ResourceFork

[rxgh99]

Describe the bug A file's original "modified date" on macOS is not preserved on restore of that file when the file has a resource fork (com.apple.ResourceFork). Instead, the value of the day and time of restore is used. Note: The file's original "create date" is preserved.

Preferred outcome: all original file metadata is preserved after a restore.

To Reproduce Steps to reproduce the behavior:

1. Identify a file that has a resource fork e.g. using xattr
2. Backup file using Vorta
3. Restore file to a new location
4. Compare modified date, create date in Finder (or at filesystem)

Environment (please complete the following information):

• OS: macOS 11.2
• Vorta version: 0.7.5
• Installed from: vorta.borgbase.com
• Backend: borgbase.com

Additional context Extract was successful - no additional logging seems to provide insight.

[m3nu]

Borg should handle xattrs just fine, unless they are excluded intentionally

Can you show a minimal example using the Borg CLI only? The change will be needed there, not in Vorta.

[rxgh99]

I created a local filesystem repo with a single file (with resource fork). I used the CLI from Vorta - is this sufficient, or do you need the full CLI install?

$sudo /Applications/Vorta.app/Contents/Resources/borg-dir/borg.exe --debug -p extract --list /Users/rxgh99/_test/backup::hostname-2021-04-05-194651 Volumes/Main/Documents using builtin fallback logging configuration 35 self tests completed in 0.08 seconds Verified integrity of /Users/rxgh99/_test/backup/index.5 Enter passphrase for key /Users/rxgh99/_test/backup: TAM-verified manifest security: read previous location '/Users/rxgh99/_test/backup' security: read manifest timestamp '2021-04-06T02:46:51.795049' security: determined newest manifest timestamp as 2021-04-06T02:46:51.795049 security: repository checks ok, allowing access Volumes/Main/Documents/manual-orig.pdf indicator (might take long for large archives)

[rxgh99]

Also, I encountered an error in Vorta when attempting to extract from this local repo with one file in the archive. The error I received was:

Traceback (most recent call last): File "views/archive_tab.py", line 416, in list_archive_result File "views/extract_dialog.py", line 42, in init AttributeError: 'dict' object has no attribute 'split'

Would you like this in a separate issue? Thanks.

[m3nu]

AttributeError: 'dict' object has no attribute 'split'

This is already fixed in the current master branch. So unless you can reproduce it there, no need to reopen an issue for it.

[rxgh99]

I can also confirm this "modified date" issue restoring file with com.apple.ResourceFork is present with Borg 1.1.16.

[m3nu]

Thanks for checking. Can you provide a minimal failing example using Borg CLI? Then we can open an issue with Borg itself upstream.

[rxgh99]

Hi - there was an example provided above, captured here below. There's no failure per se in the messaging; the extract works. I have the same output result with 1.1.16.

Are there any additional flags to use that might provide more insight?

$sudo /Applications/Vorta.app/Contents/Resources/borg-dir/borg.exe --debug -p extract --list /Users/rxgh99/_test/backup::hostname-2021-04-05-194651 Volumes/Main/Documents using builtin fallback logging configuration 35 self tests completed in 0.08 seconds Verified integrity of /Users/rxgh99/_test/backup/index.5 Enter passphrase for key /Users/rxgh99/_test/backup: TAM-verified manifest security: read previous location '/Users/rxgh99/_test/backup' security: read manifest timestamp '2021-04-06T02:46:51.795049' security: determined newest manifest timestamp as 2021-04-06T02:46:51.795049 security: repository checks ok, allowing access Volumes/Main/Documents/manual-orig.pdf indicator (might take long for large archives)

Thanks.

[m3nu]

I meant the steps to reproduce and verify the issue. Not just the extract command. E.g. I'm not fully sure where the xattr comes from. I just know files downloaded in Safari have it. So would this be the right steps?

# Add test file
$ touch test

# Set some xattr
$ xattr -w foo bar test

# Verify xattr is set
$ xattr test
foo

# Create new Borg backup
$ borg create ...

# Extract file
$ borg extract ...

# BUG: xattr is missing!!!
$ xattr my/extracted/folder/test
---

[rxgh99]

Sorry for the mix-up. Your steps are accurate:

# Add the test file
$ touch test.txt

# Add com.apple.ResourceFork
$ xattr -w com.apple.ResourceFork mytestrf test.txt

# Check resource fork is present
$ xattr -p com.apple.ResourceFork test.txt
mytestrf

# Note create date and modified date of original file in Finder

# backup
$ borg ...

# Wait a period of time before restoring to ensure delta to modified date is clear

# restore
$ borg extract...

# Check restored modified and create date in Finder
# Note: com.apple.ResourceFork is restored and is present ($ xattr -p com.apple.ResourceFork test.txt)
# Modified Date of file is time of restore, not original modified date of file

[m3nu]

Just tried this with Borg by itself and I was unable to reproduce the issue:

10771  touch test.txt
10772  xattr -w com.apple.ResourceFork mytestrf test.txt
10774  borg create test-repo::xattr test.txt
10775  mkdir restore
10778  cd restore
10779  borg extract ../test-repo::xattr
10780  ls
10781  xattr -p com.apple.ResourceFork test.txt

Final command gives this output:

$ xattr -p com.apple.ResourceFork test.txt
mytestrf

Anything I'm missing?

[rxgh99]

What was the modified time of the restored file test.txt, relative to the original modified time of the file?

In my testing, the modified time reflects the time of restore, not the original modified time of the file. This only seems to occur on files with com.apple.ResourceFork attribute.

Examples:

Original files: 
-rw-r--r--@ 1 rxgh99  staff  0 Apr  8 09:02 manual.txt
-rw-r--r--@ 1 rxgh99  staff  0 Apr 13 09:26 test.txt

Restored files: 
-rw-r--r--@ 1 rxgh99  staff    0 Apr 13 09:33 manual.txt
-rw-r--r--@ 1 rxgh99  staff    0 Apr 13 09:33 test.txt

[rxgh99]

Here's the result of restoring the same files. I added a new file to the repo: test-notes.txt. This file has extended attributes, but it does not have com.apple.ResourceFork.

No mods have been made to manual.txt or test.txt. Note how the modified date on manual.txt and test.txt are now updated. But, the original date on test-notes.txt is restored.

Restored files: 
-rw-r-----@ 1 rxgh99  staff  73 Jun 17  2020 test-notes.txt
-rw-r--r--@ 1 rxgh99  staff   0 Apr 13 12:10 manual.txt
-rw-r--r--@ 1 rxgh99  staff   0 Apr 13 12:10 test.txt

[rxgh99]

Hi @m3nu - wondered if you've been able to reproduce this issue or need additional info? Thanks!

[m3nu]

You're right. Happens here too.

Next thing I need to point out though is that this is more related to Borg than Vorta. So should be reported there.

If it only happens on macOS, it's also possible that the OS is doing some magic with such files for whatever reason. It also seems low priority, so I'm not sure this is worth pursuing for an OSS project with limited resources.

10037  touch test{1,2}.txt
ll
-rw-r--r--@  1 manu  staff     0B Jan  7 14:56 test1.txt
-rw-r--r--   1 manu  staff     0B Jan  7 14:56 test2.txt
10039  xattr -w com.apple.ResourceFork mytestrf test1.txt
10040  borg create test-repo::xattr2 test*.txt
10041  mkdir restore
10042  cd restore
10044  borg extract ../test-repo::xattr2
10046  ll
-rw-r--r--@ 1 manu  staff     0B Jan  7 14:58 test1.txt
-rw-r--r--  1 manu  staff     0B Jan  7 14:56 test2.txt

[rxgh99]

Hi Manu,

Thanks for following up and confirming. I will take a look on the Borg side for reporting, if it needs to be a separate issue that's raised.

I understand the prioritisation position; I personally view it as a restore fidelity issue - I would like to ensure that my restore is 100% of what was originally backed up and not less. Duplicacy has the same issue, but interestingly Arq does not have this issue.

Thanks again for following up.

[ThomasWaldmann]

Fixed in borg 2.0.0b5 and upcoming fix in borg 1.2.4 (not released yet, but fix already in 1.2-maint branch).