I am validating a local backup and recovery workflow using artificial files only. I would like guidance on supported quarantine handling, not a way to bypass Gatekeeper.
The recorded tests used:
- Native ditto with --rsrc --extattr --acl --qtn.
- Native pax-tar creation and restore with --mac-metadata and --fflags.
Important limitation: the quarantine markers were seeded manually in the test fixtures. These were not files quarantined through a real browser download, so I have not established that the fixtures represent normal download provenance.
Unmarked controls matched their source. In marked copy/restore cases, payload hashes and other checked metadata matched, but com.apple.quarantine differed. One earlier copy recorded a flag-prefix change from 0081 to 0281; other marker fields also changed.
Original marker bytes can be retained exactly as archive data, but that does not explain the security effect of the native-restored value. I have not stripped or normalized restored markers, changed Gatekeeper settings, or tested execution of the restored files.
An earlier project record lists macOS 26.5.1. The current OS build and exact native-tool versions have not been refreshed for this question.
Could you clarify:
- Is manual marker seeding a supported way to test copy/restore behavior, or should this be evaluated using an OS-managed quarantine event instead?
- Can these native operations intentionally change quarantine state, and which documented interfaces or guidance establish the meaning and security impact?
- Is preserving the original bytes as archive evidence while leaving native-restored metadata untouched the supported approach?
- What checks or supported options should a recovery workflow use without rewriting the marker or weakening Gatekeeper?
I am not claiming this is a macOS vulnerability or that the changed value is harmless. No business files, private logs or attachments are included.