Re: Time Machine's volume uuid -- what does it match against?
Re: Time Machine's volume uuid -- what does it match against?
- Subject: Re: Time Machine's volume uuid -- what does it match against?
- From: Michael Watson <email@hidden>
- Date: Wed, 20 Jul 2016 15:08:05 -0700
by the way, if you can't talk about the details of your software on a public list, i definitely understand that. i really wish i knew more about what your software does, though, so i could give the best possible advice.
so you have a userland process, and you want to manage access to devices that can be ejected. it sounds like you *don't* want to manage Time Machine backup disks in this way. do i have that right?
there are a bunch of things to keep in mind. the following list is probably not exhaustive.
- a machine can have more than one backup disk.
- a backup disk can a mounted disk image volume.
- a disk with Time Machine backups can be connected to a machine that isn't configured to use that disk as one of its backup disks.
- users can add and remove (configure/unconfigure, not attach/detach) backup disks in the Time Machine preferences pane and via tmutil(8) at any time.
- adding a new backup disk to the Time Machine configuration doesn't instantly create a Backups.backupdb directory (the "backup store"). that directory is created when a backup starts. (this is important to remember in case you're looking for the backup store.)
there's no publicly supported way to get a list of all the volume UUIDs (or device IDs) for backup disks, whether connected or not, whether configured to be the current machine's backup disk or not. most situations where apps need to care about Time Machine backups are situations where apps want to ignore backups, which almost always translates to "ignore the Backups.backupdb directory on any disk" instead of actually caring about devices. i don't know the details about your situation and code, but is it reasonable for your app to see whether a backup store exists on a volume in order to make its decision(s)?
--
On 20 Jul, 2016, at 13:44, Jim O'Connor <email@hidden> wrote:
> I’m managing access to ejectable media. This is done at the user process level, but I have a root process I can farm work to if I need to. A kernel extension would be a possibility if necessary since we’re using kexts for other work, but that isn’t within the reach of my current deadline.
> I don’t want to prevent access to the blessed TM partition for the machine.
> Other media are evaluated based on policy and content.
>
> On Jul 20, 2016, at 12:33 PM, Michael Watson <email@hidden> wrote:
>
>> what i mean by "higher-level goal" is more like:
>>
>> what is your software actually doing that you want to ignore things at the device level? what context does your code run in? (IOKit driver? daemon? userland app?) what does "different handling" mean?
>>
>> you are correct that you can never assume the volume name of a backup disk. you *can* assume the name of the backup store folder, which is always "Backups.backupdb", and it lives at the root of the volume.
>>
>>
>> --
>> michael
>>
>>
>> On 20 Jul, 2016, at 12:15, Jim O'Connor <email@hidden> wrote:
>>
>>> Hi Michael,
>>>
>>> Thanks for your response.
>>>
>>> My higher level goal is to recognize partitions that TM will actively try to use on so I can avoid them. Media with TM data not related to this machine need different handling. I need to be sure I don’t interfere with TM in any way.
>>>
>>> I don’t believe using the partition name alone will be sufficient.
>>>
>>> Thanks,
>>> Jim
>>>
>>> On Jul 20, 2016, at 10:37 AM, Michael Watson <email@hidden> wrote:
>>>
>>>> hi Jim,
>>>>
>>>> the ID emitted by the destinatininfo verb is not a volume UUID. it's a unique identifier used by Time Machine to track a collection of information about a specific backup destination. (we refer to it as the "destination ID".) the ID is used with other verbs like removedestination:
>>>>
>>>> sudo tmutil removedestination <destination_id>
>>>>
>>>> what's your higher-level goal? for most "i need to ignore TM stuff" situations, it's sufficient (and most-correct) to ignore the Backups.backupdb directory at the root of any volume. (for example, a disk with a TM backup store could be connected to a machine but not be one of that machine's backup disks.)
>>>>
>>>>
>>>> --
>>>> michael
>>>> formerly time machine
>>>>
>>>>
>>>> On 20 Jul, 2016, at 10:03, Jim O'Connor <email@hidden> wrote:
>>>>
>>>>> On El Cap (10.11.5) when I do
>>>>>
>>>>> tmutil destinationinfo -X
>>>>>
>>>>> I get a uuid which doesn’t match anything in
>>>>>
>>>>> diskutil info devnode
>>>>>
>>>>>
>>>>> Where do I look to get the same UUID that Time Machine is using? I need to avoid the media that the OS is using for Time Machine.
>>>>>
>>>>>
>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd";>
>>>>> <plist version="1.0">
>>>>> <dict>
>>>>> <key>Destinations</key>
>>>>> <array>
>>>>> <dict>
>>>>> <key>Kind</key>
>>>>> <string>Local</string>
>>>>> <key>ID</key>
>>>>> <string>EEDAB9D5-740E-4E11-BC39-52A4B6E58638</string>
>>>>> <key>Name</key>
>>>>> <string>TimeMachineHD</string>
>>>>> <key>LastDestination</key>
>>>>> <integer>1</integer>
>>>>> <key>MountPoint</key>
>>>>> <string>/Volumes/TimeMachineHD</string>
>>>>> </dict>
>>>>> </array>
>>>>> </dict>
>>>>> </plist>
>>>>>
>>>>>
>>>>> Device Identifier: disk2s2
>>>>> Device Node: /dev/disk2s2
>>>>> Whole: No
>>>>> Part of Whole: disk2
>>>>> Device / Media Name: TimeMachineHD
>>>>>
>>>>> Volume Name: TimeMachineHD
>>>>>
>>>>> Mounted: Yes
>>>>> Mount Point: /Volumes/TimeMachineHD
>>>>>
>>>>> File System Personality: Journaled HFS+
>>>>> Type (Bundle): hfs
>>>>> Name (User Visible): Mac OS Extended (Journaled)
>>>>> Journal: Journal size 155648 KB at offset 0x3a38000
>>>>> Owners: Enabled
>>>>>
>>>>> Partition Type: Apple_HFS
>>>>> OS Can Be Installed: Yes
>>>>> Media Type: Generic
>>>>> Protocol: USB
>>>>> SMART Status: Not Supported
>>>>> Volume UUID: 5A69DD5E-D6B9-31B7-8CD6-FC377EBC5F18
>>>>> Disk / Partition UUID: 620E6E7B-7C47-4930-B5F7-5C7E68C3B025
>>>>>
>>>>> Total Size: 2.0 TB (2000054960128 Bytes) (exactly 3906357344 512-Byte-Units)
>>>>> Volume Free Space: 2.0 TB (1993384857600 Bytes) (exactly 3893329800 512-Byte-Units)
>>>>> Device Block Size: 512 Bytes
>>>>> Allocation Block Size: 4096 Bytes
>>>>>
>>>>> Read-Only Media: No
>>>>> Read-Only Volume: No
>>>>>
>>>>> Device Location: External
>>>>> Removable Media: No
>>>>>
>>>>>
>>>>> Thanks for looking.
>>>>>
>>>>> Jim
>>>>> _______________________________________________
>>>>> Do not post admin requests to the list. They will be ignored.
>>>>> Filesystem-dev mailing list (email@hidden)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>
>>>>> This email sent to email@hidden
>>>>
>>>>
>>>> _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> Filesystem-dev mailing list (email@hidden)
>>>> Help/Unsubscribe/Update your Subscription:
>>>>
>>>> This email sent to email@hidden
>>>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Filesystem-dev mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden