Path: news1.icaen!news.uiowa.edu!iagnet.net!iagnet.net!ais.net!nntprelay.mathworks.com!intgwlon.nntp.telstra.net!news.telstra.net.nz!news.wlg.netlink.net.nz!news.actrix.gen.nz!dempson From: dempson@actrix.gen.nz (David Empson) Newsgroups: comp.sys.apple2 Subject: Re: GS/OS applications on HFS disks Date: Fri, 29 May 1998 01:29:42 +1200 Organization: Empsoft Lines: 57 Message-ID: <1d9rhc8.oi6jledfzyeoN@dempson.actrix.gen.nz> References: <356C2E36.18FD@spcgroup.nl> <1998052801553400.VAA27306@ladder03.news.aol.com> <356D1169.2C0@spcgroup.nl> NNTP-Posting-Host: news2.actrix.gen.nz X-Newsreader: MacSOUP 2.3 Xref: news1.icaen comp.sys.apple2:134519 Pim Blokland wrote: > Supertimer wrote: > > > > >However, the other day I found that when copying a GS/OS application to > > >a HFS disk (with the Finder), the aux type of the app gets destroyed. > > >The file type remains the same ($B3), but the aux type reverts to zero. > > > > Was this GS file handled with a Macintosh program (copied, Shrink II, > > etc.)? I only seen this happen ONCE. I set the file type and aux type > > Nope. It was an ordinary GS/OS desktop application (type $B3, auxtype > $DB03) which I copied to a HFS floppy using the GS Finder, and which I > then found to have an aux type of $0000. I can explain why this is happening. ProDOS files on HFS volumes are stored using an encoded file type, with a creator of 'pdos'. The normal file type encoding is the letter 'p' followed by three bytes: ProDOS file type (byte) and ProDOS auxiliary type (word - not sure about the byte order). This is a relatively recent mechanism, introduced around System 5.0. Prior to this, the encoding scheme was much simpler, and didn't allow the ProDOS auxiliary type to be preserved. Most files had an HFS file type consisting of two ASCII hexadecimal digits representing the ProDOS file type, followed by two spaces. However there were several special cases: TXT ($04) was stored as 'TEXT'. SYS ($FF) was stored as 'PSYS'. S16 ($B3) was stored as 'PS16'. (Possibly some others, but there were the main ones.) For some reason, these conversions were retained when the new mechanism was introduced. The net result is that the auxiliary type is lost for any TXT, SYS or S16 file, and should be retained for everything else. In my opinion, this is a bug. The rule for these file types should be: - If the auxiliary type is zero (or any reasonable default value, such as $0100 for S16 file), then the old encoding should be used. - If the auxiliary type contains any important information (e.g. record length for TXT files, auxtype flags for S16), then the new encoded form should be used. The disadvantage of this is that the Mac won't see such files as a "Text File" or an "Apple IIgs application", simply as a generic "ProDOS file". -- David Empson dempson@actrix.gen.nz Snail mail: P.O. Box 27-103, Wellington, New Zealand