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.
- Application packages did not exist in System 7 so obviously it
couldn't have worked this way
- 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)
- Custom folder icons were added via an "Icon^M" file to the folder
itself, which I believe would delete itself properly if the
icon were removed
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.
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.
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.
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.
|
