Path: utzoo!attcan!uunet!cs.utexas.edu!rutgers!apple!mattd
From: mattd@Apple.COM (Matt Deatherage)
Newsgroups: comp.sys.apple
Subject: Re: resource forks
Message-ID: <31038@apple.Apple.COM>
Date: 18 May 89 17:51:46 GMT
References: <890518011751.127016@DOCKMASTER.ARPA>
Organization: Apple Computer Inc, Cupertino, CA
Lines: 77

<890518011751.127016@DOCKMASTER.ARPA> TMPLee@DOCKMASTER.NCSC.MIL writes:
>(This in response to Dave Lyon's response to my question)
>
>Thanks for the answers, but they don't make me feel very comfortable.
>Will there or will there not be a usuable, reliable, incremental hard
>drive backup package available on System Disk 5.0 or available at the
>same time that can handle extended files?  Also, will the problem of the
>Finder on 4.0 continually polling my PC Transporter's drive have been
>fixed in the Finder on 5.0?  AE insists that the problem is Apple's, not
>theirs, and it is the reason why I have to stay with the old Finder (3.0
>or so System disk) which presumably would have the same problem with
>extended files that ProDos 8 does since it doesn't know anything about
>them.
>
I hasten to remind those in netland worried about extended files that they
have been present in GS/OS, and in the ProDOS FST, ever since release.  That's
nine months since release, and even longer since seeding so many developers
have been aware of this for a *long* time.  Some have revised their programs
to support extended files, others have not.  Those that haven't will probably
feel a twinge of regret.  A standard GS/OS file utility *will* operate on
extended files, even without modification, but it will not duplicate or operate
on the resource fork without change.  For example, APW's "copy" command will
copy an extended file, but only the data fork.  Not knowing about the resource
fork (since it was written before GS/OS), it will only copy the data fork.
This differs from ProDOS 8, which can't open extended files at all.

A backup utility was not announced as part of the system software, t
specifically answer your question, but please stop thinking extended files are
an incredible nuisance and the end to life as we know it.  It's not true.

PC Transporter's problems are not Apple's fault, except in a very minimal
sense of the word "fault".  The Finder makes DStatus calls to the drives to
determine their state, since in Apple II land we can eject disks without the
operating system knowing about it.  The generated driver for the PC Transporter
responds to these by going to disk.  The Finder wouldn't do this if the drives
correctly identified themselves through SmartPort as 5.25" drives, but they
don't, so the Finder has no way to know not to poll the drives.  I've seen at
least one person patch the PCT pre-boot to fix a couple of AE's bugs in it
(such as this one), and the 4.0 Finder works just fine with it.  The patches
have been given to AE, which so far hasn't seen fit to distribute them to
the installed base at large, apparently hoping Apple will fix their problems
for them (I guess, based on what you said).

>And I really don't see why you can say it is better to have new extended
>files that ProDos8 can't use than not to have them at all; that's only
>your opinion.
>
It's mine, as well.  16-bit software will usually handle the extended files
in at least a minimal, one-forked kind of way, instead of ProDOS 8 which can't
deal with them through normal operations.  So run 16-bit software.  It's the
same kind of opinion that thinks an HFS FST would be useful, even though
ProDOS 8 couldn't read those disks at all.

There are a good number of 16-bit utilities out there which duplicate and
enhance the functions of the ones you use under ProDOS 8.  If you don't
run 16-bit software for some reason, perhaps you'd be happier with a IIe and
a TransWarp card.  It's cheaper than a standard IIgs and faster.  However,
most IIgs owners expect (and receive) enhancements and new operating systems,
and realize that all of these features can't be backwards compatible.  I still
think it's pretty neat that GS/OS can recognize ProDOS 8 programs on ProDOS
or AppleShare disks and load P8, *an entirely different operating system*, so
the program can execute, and then restart itself when the program quits.  That
kind of integrated backwards compatibility doesn't show up all that often, and
it just can't always happen that smoothly.  There are such things as growing
pains.

>TMPLee@dockmaster.ncsc.mil

-----------------------------------------------------------------------------
Matt Deatherage, Apple Computer, Inc. | "The opinions expressed in this tome
Send PERSONAL mail ONLY (please) to:  | should not be construed to imply that
AppleLink PE: Matt DTS  GEnie: AIIDTS | Apple Computer, Inc., or any of its
CompuServe: 76703,3030                | subsidiaries, in whole or in part,
Usenet:  mattd@apple.com              | have any opinion on any subject."
UUCP:  (other stuff)!ames!apple!mattd | "So there."
-----------------------------------------------------------------------------