I have posted my code at: https://github.com/jwwalker/SetDmgOpenFolder

Alternative way to make a disk image that opens a folder automatically: sudo hdiutil makehybrid -hfs -hfs-openfolder open-folder-path -o image-path source-path

P.S. My code works with a volume using the HFS+ file system, but not with a volume using APFS. In the latter case, setattrlist reports EINVAL.

I think I've got it. The Finder info of an old disk image that auto-opens its root directory: 00000000 00000000 00000002 00000000 00000000 00000000 5A156DD7 DA8B129A The Finder info of a newly created read-write disk image: 00000000 00000000 00000000 00000000 00000000 00000000 28F57114 97D99395 In both cases, the frOpenChain field (the 4 bytes starting at offset 20) is zero, so that doesn't seem to be what's used for this purpose. One clear difference between the two is the frLocation.v field, the 2 bytes at offset 10. That appears to be the iNode number of the folder you want to open as a Finder window, represented as a bigendian 16-bit number. Setting that does seem to do what I want!

Never mind, looks like I can call getattrlist with ATTR_CMN_FNDRINFO and ATTR_VOL_INFO. Now I'll see if I can figure out anything about the results.

@DTS Engineer Can you give me a clue on how to access Finder info for a volume? I know that there's an extended attribute for Finder info, but getxattr takes a path, and I don't know how to make a path that refers to a volume rather than its root directory. I tried the deprecated function FSGetVolumeInfo, but it returned paramErr when I passed kFSVolInfoFinderInfo.

You need to run a run loop in your thread. See: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Multithreading/RunLoopManagement/RunLoopManagement.html

Did you try QuickLook thumbnailing? I would have thought it would work. An alternative: -[NSWorkspace iconForFile:]

I tried Quinn's program once more under macOS 14.5 on my Intel-based Mac, and saw flowsw instead of 10 TCP sockets. So it appears that the difference is Sonoma versus Ventura.

Yes, the Mac App Store mandates sandboxing, but no, sandboxing does not prohibit Accessibility permission. In fact I have two apps in the Mac App Store that can request and use Accessibility permission.

I did the test again on a different Mac on the same local network, this time running macOS 14.5. And then I saw the flowsw thing instead of 10 TCP sockets. Another difference between the machines is that the one running Ventura has an Intel CPU, while the one with Sonoma is M1.

By the way, since the skywalkctl command was recommended here, I want to make a couple of comments about it. First, it can only be run using sudo. Second, the man page says you can get help on a command using skywalkctl COMMAND help, but that doesn't work.

I tried Quinn's test program, and I did see 10 TCP sockets. MacOS 13.6.7. I have iCloud+ but had Private Relay turned off. (Private Relay is part of iCloud+). No VPN.

The documentation of NSWorkspaceWillPowerOffNotification says To receive this notification, use notificationCenter to register for it. If you use a different notification center to register, you won’t receive the notification. That is, when you add the observer, you need to use NSWorkspace.notificationCenter instead of NotificationCenter.default.

In the first approach, do you see your imported certificate and private key under "My Certificates" in Keychain Access? Do you see your imported certificate in Xcode's Settings > Accounts when you click "Manage Certificates"?