SplitForks tool on 10.4.x and custom icons
SplitForks tool on 10.4.x and custom icons
- Subject: SplitForks tool on 10.4.x and custom icons
- From: Mike Fischer <email@hidden>
- Date: Tue, 24 May 2005 05:06:23 +0200
Hi,
a friend of mine and I where having problems with getting a custom icon
set on a folder after installing from a package (.pkg) file. At first
it looked like this was an Iceberg bug but further testing in
conjunction with the very helpful author of Iceberg pointed towards the
SplitForks tool which is being used by Iceberg.
Basically what happens is this:
When a custom icon is set on a folder the Finder generates an "Icon\r"
file inside the folder with the resource fork containing the icon. And
it sets the kHasCustomIcon flag in the FinderInfo of the folder.
When the SplitForks tool encounters such a folder it should generate
the following structure of files:
./._<foldername> Attributes for the folder
./<foldername>/ The folder with the custom icon
./<foldername>/._Icon\r Attributes and resource fork of the "Icon\r"
file
./<foldername>/Icon\r The (empty) data fork of the "Icon\r" file
The ._ files are the AppleDouble header files containing the (Finder)
attributes and the resource fork if present for the corresponding
file/folder.
This all works fine upto here. But when the 10.4.x SplitForks tool is
run on <some> 10.4.1 systems (not all surprisingly, but I know two
where this happens 100% of the time) the ._<foldername> file contains
the string "Mac OS X " in bytes 9 through 24 (starting at offset
8). These 16 bytes are officially declared as "Filler" in RFC 1740 and
should be set to 0x00. RFC 1740 describes version 0x00020000 of the
AppleDouble format which is generated by the SplitForks tool. They had
a slightly differnt meaning in older versions of the AppleDouble format
though (Home file system in version 0x00010000).
When this happens the kHasCustomIcon flag is not set on the resulting
folder when installing on 10.4.1. (It does work on 10.3.9 and 10.2.8
though.) The SplitForks tool on 10.3.9 does not have this problem (to
my knowledge).
Patching those 16 bytes to contain 0x00 fixes the problem.
The conclusion is that the SplitForks tool sometimes writes illegal
content into these bytes and some other part of the OS is picky about
this in 10.4.x systems and probably rejects the files as illegal.
Here is a hexdump of the original ._<foldername> file as generated on
said 10.4.1 system:
00000000 00 05 16 07 00 02 00 00 4d 61 63 20 4f 53 20 58
|........Mac OS X|
00000010 20 20 20 20 20 20 20 20 00 02 00 00 00 09 00 00 |
........|
00000020 00 32 00 00 00 20 00 00 00 02 00 00 00 52 00 00 |.2...
.......R..|
00000030 00 00 00 00 00 00 00 00 00 00 04 00 00 00 00 00
|................|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|
*
00000050
The patched (working) version looks like this:
00000000 00 05 16 07 00 02 00 00 00 00 00 00 00 00 00 00
|................|
00000010 00 00 00 00 00 00 00 00 00 02 00 00 00 09 00 00
|................|
00000020 00 32 00 00 00 20 00 00 00 02 00 00 00 52 00 00 |.2...
.......R..|
00000030 00 00 00 00 00 00 00 00 00 00 04 00 00 00 00 00
|................|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|
*
00000050
I found this very odd and decided to check where the string "Mac OS X"
is coming from. Neither Iceberg nor the SplitForks tool contain this
string AFAICT. I used otool to disassemble the SplitForks tool and
while I can see exactly where the AppleDouble file header is written I
see no way anything other than 0x00 could be written to bytes 9-24 as
the memory is initialized to zero using memset() and not touched until
the FSWrite() call.
I'll gladly post an official bug report but I feel I'm missing
something here. I don't really believe in magic (mostly ;-) but I'm
seeing results that seem to be impossible.
Does anyone have a clue as to what is going on here?
Thanks!
Mike
--
Mike Fischer Softwareentwicklung, EDV-Beratung
Schulung, Vertrieb
Web: <http://homepage.mac.com/mike_fischer/index.html>
Note: I read this list in digest mode!
Send me a private copy for faster responses.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden