volumeUUIDString missing

Hi,


does anyone know the reason why a mounted volume might not ave a `URLResourceValues.volumeUUIDString`?


I have two mostly identical SD Cards (same size, formatted in the same camera). One has a volumeUUIDString when mounted and the other has none.

The documentation for volumeUUIDString only says:

"The volume's persistent `UUID` as a string, or nil if a persistent `UUID` is not available for the volume.". So no real explanation given why there might be no volumeUUIDString. Or what might be another option for uniquely identifying a volume.


Any hints, info highly appreciated.


Cheers, Michael

Presumably the volume format is some flavour of FAT? ISTR that FAT volumes store their UUID in as special directory entry and it’s possible that this entry is missing on one of your cards. However, that’s just a theory. It’s hard to say for sure without digging into the volume format.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thank you, Quinn, for the quick clarification.

Do you have any suggestion what else (other than writing a "dot" file withe a UUID) could be used to uniquely identify a volume? Or do you think that writing a file with a UUID is my best bet?


Thanks again, Michael

This is a hard problem even if you have a volume UUID because it’s not uncommon for folks to clone a volume in a way that the UUID ends up being cloned as well.

Why do you need to identify the volume?

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

If coling the volume means, that the content is cloned as well, then that could be fine for my use case (well actually there might be edge cases where it would not). So let me explain why I want to do it:

Essentially what I am trying to do (on an abstract level), is to write an application which catalogues files, which may or may not be stored on external drives. Some metadata of those files would be stored locally in an import step and also available if the external drive is not connected. If the user needs to access the original file, the application should be able to detect if the proper drive and thus the file (if not deleted, etc.) is available or not.

On a not so abstract level: Think of cataloging photos from SD cards from the same camera. Using the SD cards basically as film rolls, meaning never overwriting them. If the original photo needs to be retrieved, the SD card may be plugged in, is automatically detected and the file can be retrieved.


Not sure if my explanation is good enough, though. ;-)


Thanks, Michael

Have you tried using bookmarks for this? Historically macOS put a lot of effort into handling external drives reliably and much of that continues to look at the core of bookmarks. It might be sufficient for your requirements, and it would save a lot of work messing around with low-level goo.

Then again, it might fail horrible (-:

Still, it’s worth building a quick prototype.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Bookmarks! That was the hint I needed :-)

So far testing looks good: Both the good and the problematic SD cards were identified correctly.

Thanks for the help, Quinn! I'll make sure to have the proper coding in place, for cases when the approach with the bookmarks fails horribly.


Cheers, Michael

volumeUUIDString missing
 
 
Q