I tried it in Objective-C, and it does work, but it's not super obvious how it works. If you look up NSDirectoryEnumerationIncludesDirectoriesPostOrder in the header, comments say: NSDirectoryEnumerationIncludesDirectoriesPostOrder causes the NSDirectoryEnumerator to enumerate each directory a second time after all of its contained files have been enumerated. Use NSDirectoryEnumerator.isEnumeratingDirectoryPostOrder to differentiate a post-order enumerated directory from a pre-order one. What this means is that the enumerator visits a directory, then visits the contents of the directory, and then visits the directory again, and the second time, the isEnumeratingDirectoryPostOrder property of the enumerator is true. Maybe you should file a feedback about the documentation.

Correction: In order for the softwareupdate tool to find the Sequoia beta, you must have the Sequoia beta update channel turned on:

Thanks for your reply, but I'm not actually asking for help in interpreting this particular crash log. As I indicated in my first post, I have already used the atos command line tool to figure out the symbols in my app involved in the crash. I was just wondering whether there is an easier way to handle future crash logs. The links you provided for symbolicating crash reports using Xcode does not appear relevant to Mac crashes. It says "click the Device Logs button in the Devices and Simulators window, then drag and drop the crash report file into the list of device logs", but I have nothing under Devices, and in particular no Device Logs button.

It turns out it is possible to get a full installer for the Sequoia beta: softwareupdate --fetch-full-installer --full-installer-version 15.0 And running that installer, I didn't get the weird error.

Tried to install Sonoma on an empty volume a couple of times, and got this: My Internet connection was good enough to download the installer. Maybe everyone is doing this and the server is overloaded?

It was suggested that maybe the control gets deallocated on a thread other than the main thread, but I set things up to write to a log file whenever an NSSegmentedControl gets a dealloc message off the main thread, and that's not happening.

I'll be darned, thank you very much for the documentation link!

Thanks for the additional information, which I assume is all undocumented except the part about Finder info using bigendian order.

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