Hello, I am working on a backup process on macOS. Before copying files, the script needs to check that it is looking at the correct mounted backup volume. A fictional example A user opens an encrypted disk image called ExampleBackup.sparsebundle and enters the password themselves. The volume then appears in Finder as ExampleBackup. Before copying anything, the script needs to confirm: This mounted volume actually belongs to the intended disk image. The volume is mounted read/write. File ownership is being enforced. The destination has not been replaced or changed since the previous check. Simply checking the volume name or its path does not seem sufficient: another volume could have the same name, or a device name could be reused after ejecting and reconnecting an image. My questions What supported macOS API or command should a script use to establish this relationship reliably? Can we rely on specific fields from hdiutil info -plist and diskutil info -plist <device>? If so, where are their meanings and limitations documented? How should the script distinguish “no” from “unknown” when information is missing or a check fails? What should it check again immediately before copying, since the volume could change between separate checks? The checks themselves should only read information. They should not unlock or mount images, change permissions, or disable any security protections. If the script cannot confirm the destination safely, it should stop. A recommended approach or small example would be very helpful. Thank you.

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.