Why is the SPUSBDataType missing from system_profiler?

CStringer42 wrote:

I didn't say *all* bugs get fixed! That would be crazy! ;)

This is Apple. We're not talking "all". We're talking "any".

What was nice about SPUSBDataType was that you could correlate a physical USB drive with the mounted volume, quite easily. Unfortunately I'm unable to use IOKit (or other "lower-level" APIs) on this application, which would provide the same information (though not nearly as easily!)

That's too bad. There's quite a large community of people, mainly IT admin folks, who are trying to build various kinds of "high level" applications using only command-line tools. But they don't realize, or can't accept, that macOS died years ago. All devices are just iPhones now. All of those command-line tools will go away eventually.

There's another piece you might be missing. You can look at the Disk Arbitration framework. It's still a code-level API, but not as low-level as IOKit. I find it useful as a bridge between the highest level view, like mount paths or device names, providing pointers into IOKit where you can get more detail. And sometimes DA has quite a bit of detail on its own.

It is possible to write quasi-script tools using Swift using these APIs.

Officially, from highest to lowest, there is:

The URL class

The FileManager class

BSD

Disk Arbitration

IOKit

But trying to identify hardware specifics, such as bus protocol, versions, etc. is extremely difficult, and sometimes impossible. USB devices are relatively easy. You could brute force those. You can't distinguish between internal NVMe and Thunderbolt without IOKit. And I haven't found any reliable way to determine protocol versions in many cases.

CStringer42 wrote:

I'm a software engineer

I used to be. But after immigrating to Canada, I learned that's a regulated title. So now I'm just a software developer. But at least my satellites are still in orbit. 😄 🛰️ Most "software engineers" couldn't say as much.

I can assure you that yes, bugs do get fixed!

Not necessarily. Bugs that you or I might release will probably get fixed, but Apple generally doesn't fix bugs. Instead, they have an army of 20-something software engineers who re-write everything on iOS, and then port that to macOS. That means there's likely different behaviour every year. Sometimes, bugs that existed in past years might not exist in the current build. But that doesn't mean that anyone "fixed" them per se. It just means they were "overcome by events".

It becomes much more difficult for us, however, when a company like Apple decides to change something like this, as this change has broken one of my applications, and there is no documentation on it that I can find thus far.

You should still consider yourself lucky. The "system_profiler" tool can do machine-readable output, so in Apple Developer terminology, that's "almost API".

The "SPUSBDataType" flag listed all attached physical USB devices. "SPUSBHostDataType" only returns the "host" controllers. Missing are the USB devices that are actually attached to those host controllers, and a lot of information about them that is very difficult to ascertain (programmatically) otherwise.

It seems to work for me. When I plug in a USB drive, my EtreCheck output now says:

USB:

    USB 3.1 Bus

        PSSD T7

    USB 3.1 Bus

        <Empty>

There's actually more data there that I could be using. If I grabbed the USBDeviceKeyLinkSpeed and the USBDeviceKeyVendorName fields, it could say something like this:

USB:

    USB 3.1 Bus

        Samsung PSSD T7 (10 Gb/s)

    USB 3.1 Bus

        <Empty>

But that's a bug fix for another day.

Most of this information is just pulled from IOKit. You can get that without spawning a separate process. Sometimes it's useful.

I was hoping someone with insider info might be able to help. Waiting to hear back from Apple Developer support, so we'll just wait and see!

Good luck with that! For better or worse, this is as good as it gets.

post the command

what exact Mac

what exact macOS

paint a bigger picture—old issue, new issue, what changed...

CStringer42 wrote:

In Tahoe, the "SPUSBDataType" flag is missing from the "system_profiler" command. Is this a bug that will be fixed? And note, the "SPUSBHostDataType" flag does *not* produce the same information.

re:

system_profiler SPUSBDataType

deprecation here does not seem isolated to the macOS 26.x Tahoe. Not sure how far back you have to go(?)

going back to Sequoia I noted——deprecated.

system_profiler SPPCIDataType   

there is a old ref link— information categories you can /or could choose to retrieve

https://macdevelopers.wordpress.com/2014/01/24/programmatically-retrieving-system-information-on-mac/

CStringer42 wrote:

Why is the SPUSBDataType missing from system_profiler?

We can't ever answer any "why" questions. All we can do is offer suggestions on how to accomplish what you're trying to do.

In Tahoe, the "SPUSBDataType" flag is missing from the "system_profiler" command.

Yep.

Is this a bug that will be fixed?

Do bugs ever get fixed?

And note, the "SPUSBHostDataType" flag does *not* produce the same information.

What's missing?

CStringer42 wrote:

Thanks for the reply – where do you see SPUSBDataType as deprecated?

m̶a̶y̶b̶e̶ ̶a bad choice of words on my part...

I saw it returned "no results" going back to Sequoia my example was:

system_profiler SPPCIDataType