The title I’m starting here isn’t very helpful and is also kind of vague, so I’ll try to describe here what the title can’t, along with a bit of background.
Some background on why I’m posting:
For many years, I’ve maintained an archival library of music on which I’ve been curating since about 1989. I use the library as my own personal collection, but also as the source for when I do DJing sets. My iTunes 10.6.3 library for the collection also lives on here.
One thing I do with directories in this collection is to paste the image of title’s sleeve art into the parent directory in Finder, creating a custom icon in lieu of a generic folder. File/directory icons are handled by the ICNS resource in the resource fork.
For artists with multiple nested titles/items (e.g., Ryuichi Sakamoto, whose directory contains tens of his works, each work within being their own directories and whose icon is the sleeve art of that work), I came up with my own personal convention for marking a top-level directory.
This convention comes from a Photoshop template I created back in, like, 2014. I use it to plug in names, a big glyph based on the surname or filing name, and a unique hue I assign to all top-level directories sharing the same big glyph (e.g., “A”, “P”, “J”, etc.).
A good example: all artists/bands indexed by letter “S” — Sade, Shiina Ringo, Stacey Q, etc. — use black text and a magenta background. You can see this in the following example here with the directory for “AL STEWART” (which is for, obv., Al Stewart).
In Mojave 10.14.6:
The bug/issue
This issue, or bug only came to my notice very recently.
And I think I know why, but I don’t know mechanism what is causing it. But it is replicable.
Much of the original pasting of directories back in 2014 were prepared and done in Finder from a system running 10.6.8.
I added a great deal of new items in the past year, however, and these were added from Macs running either 10.13.6 or 10.14.6. The method for creating the custom index letter icons was done the same way as always. I hadn’t noticed anything amiss.
This week, I brought the external drive containing the library original/working drive over to my Power Mac G5 running 10.5.8 Server.
In the past, as with present, I use Carbon Copy Cloner 3.4.7 on there to manually back up the external drive’s newly added and revised contents to a server location dedicated to this backup.
What I only just noticed, however, and which has probably been the case this whole time, is any newly-pasted ICNS/icons which were pasted to the directories in High Sierra or Mojave appear as blank icons in Leopard.
In 10.5.8:
The reason I probably hadn’t noticed before was because, until recently, I hadn’t added any directories which would have appeared at the top of the directory listing (in alphabetical order). Now that I have, though, I’m seeing this feature/bug.
To be sure, I opened both the external drive and also network-connected to its cloned backup from another Mac running Snow Leopard (one which has never been involved with my archival work). The icons render just fine.
In 10.6.8:
So this becomes a question I can’t answer, but I’m sharing it with folks anyhow.
The quirk may have emerged in the way finder in macOS, no later than High Sierra and possibly further back. Unfortunately, I have no Macs running Lion through Sierra on which I could test to determine when this quirk emerged. But whatever it is, the issue seems to involve the way the ICNs resource fork data: along the way, something very minor was changed — something which an older system can’t seem to parse properly.
To be sure, I pulled out Build 10A96 of Snow Leopard and had a look from there (whose code base precedes 10.5.8 by several months and whose Finder is Carbonized still). Unpolished gremlins in 10A96 notwithstanding, the quirk seen in Leopard is also seen here.
Conclusion (?)
Something changed in the way Finder managed ICNS/icons in the resource fork from Snow Leopard, forward.
Snow Leopard can correctly parse ICNS/icons added in by later versions of macOS; Leopard (and the Carbonized Finder in PowerPC builds of Snow Leopard developer) cannot, apparently. Leopard can render the ICNS/icons added in by, at least, Snow Leopard, but along the way, ICNS/icons pasted and created in a later build of OS X/macOS stops playing nicely with pre-Snow Leopard.
Unfortunately, I don’t know why. And I’m also not going to, retroactively, fix these icons for Leopard, because all the work of assembling the library happens on Intel Macs running Snow Leopard or greater.
Some background on why I’m posting:
For many years, I’ve maintained an archival library of music on which I’ve been curating since about 1989. I use the library as my own personal collection, but also as the source for when I do DJing sets. My iTunes 10.6.3 library for the collection also lives on here.
One thing I do with directories in this collection is to paste the image of title’s sleeve art into the parent directory in Finder, creating a custom icon in lieu of a generic folder. File/directory icons are handled by the ICNS resource in the resource fork.
For artists with multiple nested titles/items (e.g., Ryuichi Sakamoto, whose directory contains tens of his works, each work within being their own directories and whose icon is the sleeve art of that work), I came up with my own personal convention for marking a top-level directory.
This convention comes from a Photoshop template I created back in, like, 2014. I use it to plug in names, a big glyph based on the surname or filing name, and a unique hue I assign to all top-level directories sharing the same big glyph (e.g., “A”, “P”, “J”, etc.).
A good example: all artists/bands indexed by letter “S” — Sade, Shiina Ringo, Stacey Q, etc. — use black text and a magenta background. You can see this in the following example here with the directory for “AL STEWART” (which is for, obv., Al Stewart).
In Mojave 10.14.6:
The bug/issue
This issue, or bug only came to my notice very recently.
And I think I know why, but I don’t know mechanism what is causing it. But it is replicable.
Much of the original pasting of directories back in 2014 were prepared and done in Finder from a system running 10.6.8.
I added a great deal of new items in the past year, however, and these were added from Macs running either 10.13.6 or 10.14.6. The method for creating the custom index letter icons was done the same way as always. I hadn’t noticed anything amiss.
This week, I brought the external drive containing the library original/working drive over to my Power Mac G5 running 10.5.8 Server.
In the past, as with present, I use Carbon Copy Cloner 3.4.7 on there to manually back up the external drive’s newly added and revised contents to a server location dedicated to this backup.
What I only just noticed, however, and which has probably been the case this whole time, is any newly-pasted ICNS/icons which were pasted to the directories in High Sierra or Mojave appear as blank icons in Leopard.
In 10.5.8:
The reason I probably hadn’t noticed before was because, until recently, I hadn’t added any directories which would have appeared at the top of the directory listing (in alphabetical order). Now that I have, though, I’m seeing this feature/bug.
To be sure, I opened both the external drive and also network-connected to its cloned backup from another Mac running Snow Leopard (one which has never been involved with my archival work). The icons render just fine.
In 10.6.8:
So this becomes a question I can’t answer, but I’m sharing it with folks anyhow.
The quirk may have emerged in the way finder in macOS, no later than High Sierra and possibly further back. Unfortunately, I have no Macs running Lion through Sierra on which I could test to determine when this quirk emerged. But whatever it is, the issue seems to involve the way the ICNs resource fork data: along the way, something very minor was changed — something which an older system can’t seem to parse properly.
To be sure, I pulled out Build 10A96 of Snow Leopard and had a look from there (whose code base precedes 10.5.8 by several months and whose Finder is Carbonized still). Unpolished gremlins in 10A96 notwithstanding, the quirk seen in Leopard is also seen here.
Conclusion (?)
Something changed in the way Finder managed ICNS/icons in the resource fork from Snow Leopard, forward.
Snow Leopard can correctly parse ICNS/icons added in by later versions of macOS; Leopard (and the Carbonized Finder in PowerPC builds of Snow Leopard developer) cannot, apparently. Leopard can render the ICNS/icons added in by, at least, Snow Leopard, but along the way, ICNS/icons pasted and created in a later build of OS X/macOS stops playing nicely with pre-Snow Leopard.
Unfortunately, I don’t know why. And I’m also not going to, retroactively, fix these icons for Leopard, because all the work of assembling the library happens on Intel Macs running Snow Leopard or greater.
