TMPLee@DOCKMASTER.NCSC.MIL (05/17/89)
I'm still troubled by the compatibility problem of introducing resource forks into ProDos. (for one thing, all the statments made in the past about the ProDos8, ProDos16, and GS/OS file systems being identical are no longer true.) someone's note about changing ECP16 to at least recognize the critters prompts me to ask a few questions ... 1. What happens when you are in old Basic.System and do a cat or catalogue command? What will it show for a file that has a resource fork (i.e., storage type 5, I think someone said it was.)? 2. When System Disk 5.0 comes out, exactly which files on it will in fact be files with resource forks? (I'm not a MAC user so I don't even know the right vocabulary -- I am right, aren't I, however in that you talk about such an animal as a SINGLE file that has two parts, the resource fork and the data fork?) Does anyone know of any applications from third party vendors that will either use, be able to use, recognize, or otherwise properly handle forked files? 3. Will a new BackUpII be issued that can handle them? (I don't remember anymore whether BackUpII was block level or file level since I never could get it to work properly; if it was block level then there is no problem.) 4. This really does sound like the most serious change to ProDos files in the compatability area for a long time -- was there any special effort made to inform the third party hardware and software vendors that would be affected by it so that they could modify/upgrade their stuff properly? (I don't know of any hardware that might be affected, but I can well imagine someone having something in on-card ROM or in utility software furnished with a device that could be affected.) I'm especially concerned about hard-drive utilities -- there are several available, as I've finally discovered, none, I repeat, none of the useful ones from Apple or Claris -- how quickly are they going to be re-issued to handle forked files? Any guesses? Until they are any serious hard drive users are going to stay away from version 5.0. TMPLee@dockmaster.ncsc.mil
dlyons@Apple.COM (David Lyons) (05/18/89)
In article <890517140423.546278@DOCKMASTER.ARPA> TMPLee@DOCKMASTER.NCSC.MIL writes: >I'm still troubled by the compatibility problem of introducing resource >forks into ProDos. (for one thing, all the statments made in the past >about the ProDos8, ProDos16, and GS/OS file systems being identical are >no longer true.) someone's note about changing ECP16 to at least >recognize the critters prompts me to ask a few questions ... It's better to have resource forks that P8 can't read than not to have resource forks at all. Since ECP16 runs under GS/OS, it has no trouble dealing with extended files (an "extended" file is one with 2 forks). ProDOS 8 programs that want to deal with either fork of an extended file have to do block-level access to the disk; this isn't recommended. >1. What happens when you are in old Basic.System and do a cat or >catalogue command? What will it show for a file that has a resource >fork (i.e., storage type 5, I think someone said it was.)? You can't tell from the BASIC.SYSTEM catalog which files are extended files and which are standard files. You can RENAME, LOCK, and UNLOCK the things, but you can't DELETE them or do anything that opens the file (even the data fork). Extended files on ProDOS disks do indeed have storage type 5. >2. When System Disk 5.0 comes out, exactly which files on it will in >fact be files with resource forks? Don't know exactly. All of the files in the system:CDEVs directory will be extended. The system:sys.resources file will obviously be extended. There are probably others. >Does anyone know of any applications >from third party vendors that will either use, be able to use, >recognize, or otherwise properly handle forked files? Anything running under GS/OS will be able to deal with the data forks of extended files, even if the application was not specially written to know about extended files. Just asking to OPEN a file under GS/OS (on System Disk 4.0 or 5.0) gets you the data fork by default. >TMPLee@dockmaster.ncsc.mil --Dave Lyons, Apple Computer, Inc. | DAL Systems AppleLink--Apple Edition: DAVE.LYONS | P.O. Box 875 AppleLink--Personal Edition: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.
delton@pro-carolina.UUCP (Don Elton) (05/19/89)
Network Comment: to #2714 by obsolete!TMPLee%DOCKMASTER.NCSC.MIL
From a CATalog, forked files look just like any other file. The change I was
discussing with ECP16 was to make forked files look different in catalog
listings since they normally don't. This is required because you have to
specify which fork you plan to open when you open a file under GS/OS 5.0.
This means that a COPY from the current ECP16 (or most any other program that
wasn't written with forked files in mind) will only copy the data fork and not
the resource fork. Right now there aren't many files that are forked on the
system disk (don't remember exactly how many) but expect to see more and more
applications with resource forks. There's an external command for APW called
DUPLICATE that's designed to copy these files until the programs get updated
and ECP16 will be updated to handle them transparently as the Finder now does.
UUCP: [ sdcsvax nosc ] !crash!pro-carolina!delton
ARPA: crash!pro-carolina!delton@nosc.mil
INET: delton@pro-carolina.cts.com
Pro-Carolina: 803-776-3936 (300-2400 baud, login as 'register')
US Mail: 3207 Berkeley Forest Drive, Columbia, SC 29209-4111delton@pro-carolina.UUCP (Don Elton) (05/19/89)
Network Comment: to #2756 by obsolete!dlyons%apple.com
Maybe I missed something but the current ECP16 knows nothing of resource forks
so I assume I have to release an update that opens and copies the data fork
followed by opening and copying the resource fork to really support them
right?
UUCP: [ sdcsvax nosc ] !crash!pro-carolina!delton
ARPA: crash!pro-carolina!delton@nosc.mil
INET: delton@pro-carolina.cts.com
Pro-Carolina: 803-776-3936 (300-2400 baud, login as 'register')
US Mail: 3207 Berkeley Forest Drive, Columbia, SC 29209-4111mattd@Apple.COM (Matt Deatherage) (05/22/89)
delton@pro-carolina.UUCP (Don Elton) writes: > >This is required because you have to >specify which fork you plan to open when you open a file under GS/OS 5.0. > >UUCP: [ sdcsvax nosc ] !crash!pro-carolina!delton >ARPA: crash!pro-carolina!delton@nosc.mil >INET: delton@pro-carolina.cts.com > >Pro-Carolina: 803-776-3936 (300-2400 baud, login as 'register') > US Mail: 3207 Berkeley Forest Drive, Columbia, SC 29209-4111 Not quite. The fork parameter has always been one of the options; if not specified, you get the data fork. Programs that don't know about resource forks obviously can't deal with them, but any utility written after GS/OS was introduced could deal with them successfully - it's just that most of them don't (including Finder 1.2 on System Software 4.0). And there is no such thing as GS/OS 5.0 - GS/OS 2.1 is included as part of System Software 5.0 (continuing the battle to get people to stop calling every part of the system software "GS/OS" :-) ) ----------------------------------------------------------------------------- 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." -----------------------------------------------------------------------------