Make a Finder window open when a disk image mounts

In this case ‘deprecated’ seems to mean ‘removed’ )-:

The whole concept of blessing a specific System Folder has gone away on Apple silicon, which is why bless no longer support this. However, it seems like --openfolder was collateral damage.

Historically the open folder chain was formed by putting the dirID of the frontmost folder in one of the volume’s Finder info words and then chaining through a value in the Finder info of each directory. Very little of this is recorded in the structures in <Finder.h> [1].

I suspect that, if you explore the Finder info of the volume of one of the existing disk images that work, you’ll see the head of the directory chain recorded there. You may even be able to set it, although it’s been years since I tried anything like that.

IMPORTANT This is the volume Finder info, not the Finder info of the volume’s root directory.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Although there is the frOpenChain field in the DXInfo structure, which was replaced a reserved field in the modern structure.

@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.

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.

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!

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.

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

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

I’m glad to hear you’re making progress.

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!

There’s a lot of stuff that’s not quite right in the above:

• frOpenChain is only meaningful in the context of the Finder info for a directory. You’re dealing with the Finder info for a volume, so that structure doesn’t apply. Instead, it’s traditional to interpret a volume’s Finder info as a simple array of UInt32 values.

• You are being similarly mislead by frLocation.v.

• You’re right that the number at offset 10 is relevant.

• Technically it’s not an inode number but an HFS [Plus] catalogue node ID (CNID). Unix-y systems tend to use that as the inode number, but only up to a limit. For example, you’ll see some divergence between the two when dealing with hard links.

• And that’s 32 bits, not 16.

• And, yes, big endian, because that’s the one true endianness (-:

not with a volume using APFS.

That’s not surprising. This is very much an old school HFS [Plus] compatibility measure.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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

which I assume is all undocumented

Oh, wow, that comment prompted me to think “Where would this documented?” and that reminded me of TN1150. And lo! it does document this stuff:

finderInfo[2] contains the directory ID of a directory whose window should be displayed in the Finder when the volume is mounted, or zero if no directory window should be opened. In traditional Mac OS, this is the first in a linked list of windows to open; the frOpenChain field of the directory's Finder Info contains the next directory ID in the list. The open window list is deprecated. The Mac OS X Finder will open this directory's window, but ignores the rest of the open window list. The Mac OS X Finder does not modify this field.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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