On 5/9/06 10:57 AM, John Stiles didst favor us with:
> Laurence Harris wrote:
>>> And you and Larry are right... I almost forgot there's the resource fork
>>> that
>>> could exist in a file...
>>>
>>
>> This is how the Finder has stored custom icons since they were introduced in
>> System 7.
>>
> That's not true.
Actually, it is.
> - Application packages did not exist in System 7 so obviously it
> couldn't have worked this way
For the purposes of this discussion an application package (or any package)
is just a folder. You've been able to add custom icons to folders since
System 7, and the mechanism for doing so has not changed since it what
introduced in System 7.
> - Custom file icons were added by writing a ICN#/icl4/icl8 resource set
> directly into the app's resource fork with a funny ID (-16xxx)
-16455 (unless you're adding a custom icon to an alias, and then it's
-16496), and the only difference now is that the Finder stores an 'icns'
resource instead of a collection of individual icon resources, but this is
just a detail and this detail wasn't mentioned previously in this thread
because it really isn't relevant.
> - Custom folder icons were added via an "Icon^M" file to the folder
> itself,
They still are, which is why this particular discussion started.
> which I believe /would/ delete itself properly if the icon were
> removed
You believe incorrectly. The "Icon\r" file has never been deleted when the
icon is removed by the Finder. Why you would even argue about this is a
mystery to me as Peter has already acknowledged that the file is not deleted
and contains an empty resource fork, which is 286 bytes. The mystery is
further deepened by the fact that you're arguing with someone who has
studied this specific issue on multiple fronts as a part of developing a
file utility that has dealt with this issue for over ten years.
>>> Just a bit surprised that after all the preaching not to use the resource
>>> fork, yet Finder still uses it... Can't blame others now, can we? :-)
>>>
>>> So, is this a known issue in Finder?
>>>
>>
>> It's been like this since System 7.
>>
> See above.
Yes, see above.
>>> Why can't Finder removed that Icon^M
>>> file when the custom icon is removed, other than a bug?
>>>
>>
>> *If* it's deliberate I would think it's because they figured another
>> application could be storing other resources in the file. That's just a
>> guess. It may be they just don't bother.
>>
> It seems like it must just be sloppiness to me. App developers have no
> reason to think that their data should be stored in an "Icon^M" file.
Application developers do all kinds of stuff you and Apple wouldn't expect.
> In fact, the rest of the bundle is off-limits for writing data, according to
> the Apple guidelines (since this breaks multi-user or non-admin configs), so
> Icon^M must be off-limits too.
None of this is specific to application bundles. See above.
> At any rate, it doesn't really matter. 286 bytes of data is not an
> issue. Assuming a reasonable data compression ratio of 2:1, that's
> 1/40th of a second for a 56k modem user to download.
Thank you for sharing your opinion. The point is that there are better ways
to accomplish the intended goal of getting the Finder to update the icon it
displays than adding a completely useless file, and I think it's a valid
point.
Larry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
This email sent to email@hidden
