tomj@pro-pac.cts.com (Tom Jenkins) (07/06/89)
And another thing...why is it that there are no programs that will allow you
to delete the newer file types on system disk 5.0? I've tried CopyIIplus,
Proterm, Cat Doctor etc all to no avail for the deletion of the newer CDEV
($C7 file types...) I had to use the original 5.0 to delete the operating
system after I found out that all my programs would not work (PCT software!)
ARGHHHHHH!!!
--
UUCP: {nosc, cacilj, sdcsvax, hplabs!hp-sdd, sun.COM}
...!crash!pnet01!pro-nsfmat!pro-pac!tomj
ARPA: crash!pnet01!pro-nsfmat!pro-pac!tomj@nosc.MIL
INET: tomj@pro-pac.CTS.COM - BITNET: pro-pac.UUCP!tomj@PSUVAX1dlyons@Apple.COM (David Lyons) (07/08/89)
In article <8907061756.AA07238@crash.cts.com> pnet01!pro-nsfmat!pro-pac!tomj@nosc.mil writes: >And another thing...why is it that there are no programs that will allow you >to delete the newer file types on system disk 5.0? I've tried CopyIIplus, >Proterm, Cat Doctor etc all to no avail for the deletion of the newer CDEV >($C7 file types...) I had to use the original 5.0 to delete the operating >system after I found out that all my programs would not work (PCT software!) > ARGHHHHHH!!! The $C7 filetype is *not* the reason you're having trouble deleting the file. (If you don't believe me, change the filetype and try to delete it then. Still no dice.) The difficulty is the STORAGE TYPE. The files in question happen to have storage type "extended", meaning that they have a resource fork. ProDOS 8 doesn't know about this storage type, so any application that uses the MLI "DESTROY" call won't be able to delete it. Applications like Copy II Plus, which go right to the block level, would need to be updated to be able to be able to deal with extended files. You can easily delete extended files under GS/OS. Just use the Finder (which is actually fun to use under 5.0, IMHO), APW, ORCA, ECP16, etc. --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.
mmunz@pro-beagle.cts.com (Mark Munz) (07/09/89)
Network Comment: to #9223 by pnet01!crash!apple.com!dlyons > The difficulty is the STORAGE TYPE. The files in question happen to have > storage type "extended", meaning that they have a resource fork. ProDOS 8 > doesn't know about this storage type, so any application that uses the MLI > "DESTROY" call won't be able to delete it. So how would one go about deleting an extended file under PRODOS 8?
dlyons@Apple.COM (David Lyons) (07/12/89)
In article <8907090816.AA20898@crash.cts.com> pnet01!pro-beagle!mmunz@nosc.mil writes: >So how would one go about deleting an extended file under P[ro]DOS 8? You don't. Unless you want to go down to the block level and delete it manually. This is not recommended, but for people who really want to do it, the necessary information can be found in ProDOS 8 Technical Note #25. (July 1989, available Real Soon Now.) --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.
mmunz@pro-sol.cts.com (Mark Munz) (07/12/89)
Network Comment: to #8743 by pnet01!crash!apple.com!dlyons >So how would one go about deleting an extended file under P[ro]DOS 8? >You don't. Unless you want to go down to the block level and delete it >manually. This is not recommended, but for people who really want to do it, >the necessary information can be found in ProDOS 8 Technical Note #25. (July >1989, available Real Soon Now.) Why can't Apple just update PRODOS to support deleting of extended files.. it seems like that would be the simplest solution. Of course, it may be that not allowing PRODOS 8 to support extended files (without doing everything manually) is part of some plot to kill the 8-bit Apple ... then again.. ;-)
orcus@pro-lep.cts.com (Brian Greenstone) (07/12/89)
Network Comment to message from pnet01!crash!pro-beagle.cts.com!mmunz This might be a dumb question, but do the SCSI.Manager & Driver on the 5.0 Tools disk make my CMS60 any faster? What are those drivers for? -Brian
farrier@Apple.COM (Cary Farrier) (07/13/89)
In article <8907121556.AA03760@crash.cts.com> pnet01!pro-sol!mmunz@nosc.mil writes: >Network Comment: to #8743 by pnet01!crash!apple.com!dlyons >Why can't Apple just update PRODOS to support deleting of extended files.. >it seems like that would be the simplest solution. If you'd seen the source code to ProDOS 8...you'd understand why. The code has been maintained by so many people that if you change a byte, chances are that you will introduce a bug. >Of course, it may be that not allowing PRODOS 8 to support extended files >(without doing everything manually) is part of some plot to kill the 8-bit >Apple ... then again.. ;-) Maybe it's time for everybody to stop worring about the rumored demise of the Apple II, less it become a self fulfilled prophecy. Notice how 3d party vendors aren't producing much software (or aren't planning on it in the near future)? They're scared by rumors. If we keep on with negative attitudes, the effect will be negative on on the Apple II family. I don't mean this as a flame, not in the least bit. I'm just expressing my views on the "death of the Apple II" rumor which doesn't seem to want to die itself. Cary Farrier +------------------------------------+ | #include "All.Standard.Disclaimers"| +------------------------------------+
dlyons@Apple.COM (David Lyons) (07/14/89)
In article <8907121556.AA03760@crash.cts.com> pnet01!pro-sol!mmunz@nosc.mil writes: >Why can't Apple just update PRODOS to support deleting of extended files.. >it seems like that would be the simplest solution. > >Of course, it may be that not allowing PRODOS 8 to support extended files >(without doing everything manually) is part of some plot to kill the 8-bit >Apple ... then again.. ;-) Then again...maybe there isn't *room* for the code. 16K isn't just gobs of room for an OS. DESTROY isn't the only command that could conceivably be modified to deal with extended files--as soon as people could delete the things, they'd also want to be able to OPEN the forks & work with them, so most of the calls would need changes. Considering that there still wouldn't be a resource manager under ProDOS 8, how useful would it be? --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.
bobl@pro-graphics.UUCP (Bob Lindabury) (07/14/89)
Network Comment: to #635 by pnet01!crash!apple.com!dlyons
Doesn't the new prodos 8 1.8x support the extended files (resource forks) for
deletion? I would expect you guys at Apple to update ProDos 8 to take care of
these matters. Is there a rewrite of Backup // in the horizon or are us Apple
// people supposed to wish we had a Mac and didn't have to worry about this
kind of stuff?
--Bob
_______________________________________________________________________________
UUCP: crash!pro-graphics!bobl | ProLine: bobl@pro-graphics
InterNet: crash!bobl@pro-graphics.cts.com | CServe: 70347,2344
ARPA/DDN: crash!pro-graphics!bobl@nosc.mil | AppleLink: Graphics3D
_______________________________________________________________________________mmunz@pro-sol.cts.com (Mark Munz) (07/15/89)
Network Comment: to #8796 by pnet01!crash!apple.com!dlyons >Then again...maybe there isn't *room* for the code. 16K isn't just gobs of >room for an OS. DESTROY isn't the only command that could conceivably be >modified to deal with extended files--as soon as people could delete the >things, they'd also want to be able to OPEN the forks & work with them, so >most of the calls would need changes. Considering that there still wouldn't >be a resource manager under ProDOS 8, how useful would it be? If Prodos 8 can no longer support the manipulation of GS/OS Extended files, they might as well be Macintosh files... what's the difference, Prodos 8 can't do anything with either (without extensive help). Worse yet is that I have to go into GS/OS every time I want to copy, delete, etc the new files, and that will take twice as long. My greatest gripe is something I didn't realize until I read it. The fact that no backup utility supports GS/OS 5.0 yet. So my hard drive happens to crash.. I can kiss a lot of work goodbye.
dseah@wpi.wpi.edu (David I Seah) (07/17/89)
In article <8907160019.AA01259@crash.cts.com> pnet01!pro-sol!mmunz@nosc.mil writes: >Worse yet is that I have to go into GS/OS every time I want to copy, delete, >etc the new files, and that will take twice as long. I use BASIC.SYSTEM to delete files and stuff, too. Faster to boot up to when you don't have a hard drive. >My greatest gripe is something I didn't realize until I read it. The fact >that no backup utility supports GS/OS 5.0 yet. So my hard drive happens to >crash.. I can kiss a lot of work goodbye. When System 5.0 is *availiable*, perhaps there will be upgraded backup utilities ready. It seems that lots of developers have been seeded with the beta version of 5.0. Being intense hard drive users, they will somehow get their files backed up. Probably one of the first 5.0 applications will be a hard disk backup! Anyway, as you appear have a hard drive, it's gonna boot up SIX TIMES as fast as it does under System 4.0! I don't think you have too much to worry about as far as boot time is concerned :) Dave Seah | ** Twinkie & Banana Club - MA ** | Internet: dseah@wpi.wpi.edu | "Manco Duck is a registered | AlinkPE: AFC DaveS | trademark of Manco, Inc" | Bitnet: dseah@wpi.bitnet
dlyons@Apple.COM (David Lyons) (07/17/89)
In article <8907160019.AA01259@crash.cts.com> pnet01!pro-sol!mmunz@nosc.mil writes: >If Prodos 8 can no longer support the manipulation of GS/OS Extended files, >they might as well be Macintosh files... what's the difference, Prodos 8 >can't do anything with either (without extensive help). "No longer"?? ProDOS 8 has never supported manipulation of extended files. I, for one, am glad to be able to use the same disks for extended files and nonextended ProDOS 8-readable files. Most of my files aren't extended. >Worse yet is that I have to go into GS/OS every time I want to copy, delete, >etc the new files, and that will take twice as long. Why is going into GS/OS a bad thing? Twice as long as what? >My greatest gripe is something I didn't realize until I read it. The fact >that no backup utility supports GS/OS 5.0 yet. So my hard drive happens to >crash.. I can kiss a lot of work goodbye. No special backup utility has to exist. Any existing ProDOS 8-based backup utility that does an image backup of your volume will work with no problem. Same for GS/OS-based image backup utilities, except possibly if you're trying to back up your boot volume. --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.
jazzman@claris.com (Sydney R. Polk) (07/18/89)
From article <33205@apple.Apple.COM>, by dlyons@Apple.COM (David Lyons): >>My greatest gripe is something I didn't realize until I read it. The fact >>that no backup utility supports GS/OS 5.0 yet. So my hard drive happens to >>crash.. I can kiss a lot of work goodbye. > > No special backup utility has to exist. Any existing ProDOS 8-based backup > utility that does an image backup of your volume will work with no problem. > Same for GS/OS-based image backup utilities, except possibly if you're trying > to back up your boot volume. This is nice if you like image backups. Unfortunately, image backups are only useful for the particular model of hard drive you are backing up. Frequently, if the hard drive dies, it gets replaced with a different one, in which case your image bcakup is useless. I need a file-by-file incremental backup, and one has to be written to deal with extended files. This way I can restore files to *any* hard drive, I can take files larger than a floppy to another hard drive, etc. It would also be nice to have a tape backup driver for Apple's 40 MB tape driver. I realize that I am asking for the moon; it just seems a shame that the OS makes all existing file-by-file backup systems obsolete and doesn't offer a utility to replace it. -- Syd Polk | Wherever you go, there you are. jazzman@claris.com | Let the music be your light. GO 'STROS! | These opinions are mine. Any resemblence to other GO RICE! | opinions, real or fictitious, is purely coincidence.
farrier@Apple.COM (Cary Farrier) (07/18/89)
In article <10398@claris.com> jazzman@claris.com (Sydney R. Polk) writes: >This is nice if you like image backups. Unfortunately, image backups are >only useful for the particular model of hard drive you are backing up. Not true. Unless your hard drive uses character i/o or something absurd, you can do block reads and writes. The only specific item needed is the driver for the hard drive, which follows specific call formats anyways. Cary Farrier +------------------------------------+ | #include "All.Standard.Disclaimers"| +------------------------------------+
mhill@pro-generic.cts.com (Martin Hill) (07/18/89)
Network Comment: to #3095 by pnet01!crash!trout.nosc.mil!pnet01!pro-graphics!bobl Why is everybody bitching about ProDOS 8 not supporting forked files? WHY does ProDOS 8 NEED to support them? It would take a lot more code to support it and there simply isn't room for it. Without a resource manager for ProDOS 8, and there is no need for that either, ProDOS should merely return an error when asked to work with a forked file. I have a question about System Disk 5.0. When and how do we get a complete update on the toolbox ref manuals, and GSOS ref manuals that explains all the new tool calls and Resource manager calls? UUCP: crash!pro-generic!mhill ARPA: crash!pro-generic!mhill@nosc.mil INET: mhill@pro-generic.cts.com
JDA@NIHCU.BITNET (Doug Ashbrook) (07/18/89)
> In article <10398@claris.com> jazzman@claris.com (Sydney R. Polk) writes: > >This is nice if you like image backups. Unfortunately, image backups are > >only useful for the particular model of hard drive you are backing up. > > Not true. Unless your hard drive uses character i/o or something > absurd, you can do block reads and writes. The only specific > item needed is the driver for the hard drive, which follows > specific call formats anyways. > > Cary Farrier Sorry, but I agree with Sydney Polk. Image backups are *NOT* the way to go. It is my understanding (after talking to Chinook's Technical Support) that you can not restore an image backup to your hard drive if the size of the partitions changes even slightly. Moreover, it is very likely that the size *WILL* change if you have to have your drive itself replaced (as I had to do recently). Fortunately, I had a file-by-file backup taken by ProSel-16's Backup program. ==================================================================== J. Douglas Ashbrook (301) 496-5181 BITNET: JDA@NIHCU <-- preferred address INTERNET: JDA@CU.NIH.GOV or jda%nihcu.bitnet@cunyvm.cuny.edu National Institutes of Health, Computer Center, Bethesda, MD 20892 -+- Remember. If some weirdo in a blue suit offers you some MS-DOS, JUST SAY NO!
farrier@Apple.COM (Cary Farrier) (07/19/89)
In article <8907181224.aa13658@SMOKE.BRL.MIL> JDA@NIHCU.BITNET (Doug Ashbrook) writes: >Sorry, but I agree with Sydney Polk. Image backups are *NOT* the way >to go. Correct me if I am wrong, but I didn't say that one way was better than the other, but thank you for offering your opinion. > [...] It is my understanding (after talking to Chinook's Technical >Support) that you can not restore an image backup to your hard drive >if the size of the partitions changes even slightly. Obviously. That is the reason that backups should be performed on a regular basis. Cary Farrier +------------------------------------+ | #include "All.Standard.Disclaimers"| +------------------------------------+
bsherman@pro-exchange.cts.com (Bob Sherman) (07/19/89)
Comment to message from: pnet01!crash!husc6.harvard.edu!m2c!wpi!dseah (David I Seah) If I read the docs correctly, PROSEL 16 and it's associated programs for backup and restore are already programed to handle the new 5.0 files. So is the 16 bit version of Cat Doctor and Beachcomber.. Glen Bredon is programming away at his mountain retreat until Labor day, so I am unable to reach him to confirm, but this is my understanding.. Also SYSTEM DISK 5.0 has now officially been released by Apple. They made the announcement yesterday... UUCP: crash!pro-exchange!bsherman ARPA: crash!pro-exchange!bsherman@nosc.mil INET: bsherman@pro-exchange.cts.com
SEWALL@UCONNVM.BITNET (Murph Sewall) (07/20/89)
>Network Comment: to #3095 by > pnet01!crash!trout.nosc.mil!pnet01!pro-graphics!bobl > >Why is everybody bitching about ProDOS 8 not supporting forked files? WHY does >ProDOS 8 NEED to support them? How about: You have a IIgs at home and a //e at work which you use as a "smart" high speed terminal to connect to a host from which you can 'ftp' all manner of software? If you want to download forked files to take home to your IIgs, will you be able to manage them? You don't want to tie up your IIgs downloading files at 1200 baud from local bbs's when you have a perfectly serviceable II+ to do that (while you use the IIgs to watch AWGS boot :-) Can you even download forked files? You want to run a Pro-Line with your //e. How do you manage forked files in your archives? Murph Sewall Vaporware? ---> [Gary Larson returns 1/1/90] Prof. of Marketing Sewall@UConnVM.BITNET Business School sewall%uconnvm.bitnet@mitvma.mit.edu [INTERNET] U of Connecticut {psuvax1 or mcvax }!UCONNVM.BITNET!SEWALL [UUCP] (203) 486-5246 [FAX] (203) 486-2489 [PHONE] 41 49N 72 15W [ICBM] -+- I don't speak for my employer, though I frequently wish that I could (subject to change without notice; void where prohibited)
gwyn@smoke.BRL.MIL (Doug Gwyn) (07/21/89)
In article <8907190556.AA29512@crash.cts.com> pnet01!pro-simasd!pro-generic!mhill@nosc.mil writes: >Why is everybody bitching about ProDOS 8 not supporting forked files? WHY does >ProDOS 8 NEED to support them? Because, for example, Apple's BACKUP 1.1.1 utility is reported to be incapable of backing up disks that contain forked files, thus leaving hard-disk users with no even semi-reasonable way to back up their disks. >Without a resource manager for ProDOS 8, and there is no need for that >either, ProDOS should merely return an error when asked to work with a >forked file. It would be much better for it to return the data fork, although that still would not help with the disk backup problem.
lhaider@pro-sol.cts.com (Lawrence Haider) (07/22/89)
Network Comment: to #8963 by pnet01!crash!pro-exchange.cts.com!bsherman
You can write to Glen Bredon at: Box 467
Huntinton Lake, CA 93629
He is on vacation, however, so don't expect a reply. Your chances for a reply
are fair if you enclose an SASE, but don't write unless you must! He's trying
to program his brains out and relax for the summer! I want to see what he did
during his summer vacation, and he promised me a major update to be released
in September (OK, maybe not _promised_, but he said watch for one) *B)
Laerlhaider@pro-sol.cts.com (Lawrence Haider) (07/23/89)
Network Comment: to #8983 by pnet01!crash!cunyvm.cuny.edu!SEWALL%UCONNVM.BITNET >You don't want to tie up your IIgs downloding files... (wile you use the IIgs >to watch AWGS boot :-) With GS/OS 3.0, AWGS boots in about 25 seconds! And, its actually usable as program to do work with! And, with a Transwarp GS, the sucka really MOVES! Its faster than most programs that I've seen on Macs!
samt@pro-europa.cts.com (Sam Theis) (07/23/89)
Comment to message from: pnet01!crash!purdue.edu!haven!adm!smoke!gwyn (Doug Gwyn)
I think that Glen Bredon's ProSEL 16 provides a little more than a
"semi-reasonable way to back up disks". It has been updated to support forked
files.
Sam
----
UUCP: {nosc, uunet!cacilj, sdcsvax, hplabs!hp-sdd, sun.com}
...!crash!pnet01!pro-nsfmat!pro-europa!SamT
ARPA: crash!pnet01!pro-nsfmat!pro-europa!SamT@nosc.mil
INET: SamT@pro-europa.cts.com - BITNET: pro-europa.uucp!SamT@psuvax1lhaider@pro-sol.cts.com (Lawrence Haider) (07/24/89)
Network Comment: to #9076 by pnet01!crash!pro-europa.cts.com!samt >I think that Glen Bredon's ProSEL 16 provides a little more than a >"semi-reasonable way to back up disks". It has been updated to support >forked files. What version is that? I got Version 7.0 but the docs only print about 20 odd pages and crashes, so I don't know if it supports forked files. I tried to repair the file but "Volume Repair" can't handle it. I figured on waiting for the next major upgrade to worry about docs, since the old docs from V6.8 seem to include most everything I need. Laer
DANFUZZ@BROWNVM.BITNET (Dan Bornstein) (07/24/89)
(Sorry about the repost; our automated system mis-sent this to just Bitnet...) >From: David Lyons <dlyons@APPLE.COM> > >In article <8907121556.AA03760@crash.cts.com> pnet01!pro-sol!mmunz@nosc.mil > writes: >>Why can't Apple just update PRODOS to support deleting of extended files.. >>it seems like that would be the simplest solution. >> ... > >Then again...maybe there isn't *room* for the code. 16K isn't just gobs of >room for an OS. DESTROY isn't the only command that could conceivably be >modified to deal with extended files--as soon as people could delete the >things, they'd also want to be able to OPEN the forks & work with them, so >most of the calls would need changes. Yes, I realize that there isn't room for resource stuff in the language card banks of RAM (funny how it's still called a "language card", no?) But, there are legitamate reasons for wanting to deal with resources on a II-non-gs, as Murph has pointed out. So, how 'bout Apple (or somebody) comes up with a set of utilities which can be included in other programs to deal with resources? Like being able to read and write files with resources without getting the odious "Unsupported file type" error. > Considering that there still wouldn't >be a resource manager under ProDOS 8, how useful would it be? Very useful for BBS programs, backup utilities, archive programs, where there are *reasons* for manipulating files that your specific computer doesn't need. -dan Bitnet: danfuzz@brownvm Internet: danfuzz@brownvm.brown.edu AppleTalk: Find me a long enough cable and I'll see what we can do.
dlyons@Apple.COM (David Lyons) (07/25/89)
In article <8907201100.aa01057@SMOKE.BRL.MIL> SEWALL@UCONNVM.BITNET (Murph Sewall) writes: [reasons P8 ought to support extended files] >How about: You have a IIgs at home and a //e at work which you use as a >"smart" high speed terminal to connect to a host from which you can 'ftp' >all manner of software? If you want to download forked files to take home >to your IIgs, will you be able to manage them? Considering that no communications programs support downloading extended files directly, this probably isn't a problem. Typically you'll download standard (nonextended) files and then unpack them as necessary. So you download at work & extract them at home. (See Apple II Miscellaneous Technical Note #14: Guidelines for Telecommunications programs, as well as the new File Type Notes for Binary II files and NuFX files. This stuff is dated July 1989. Oh, and don't forget AppleSingle and AppleDouble from May, I think.) >You want to run a Pro-Line with your //e. How do you manage forked files >in your archives? No problem...store them in an archival format as standard files. >Murph Sewall Vaporware? ---> [Gary Larson returns 1/1/90] --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.
kadickey@phoenix.Princeton.EDU (Kent Andrew Dickey) (07/26/89)
In article <8907240953.aa02146@SMOKE.BRL.MIL> DANFUZZ@BROWNVM.BITNET (Dan Bornstein) writes: > >>From: David Lyons <dlyons@APPLE.COM> >> >>In article <8907121556.AA03760@crash.cts.com> pnet01!pro-sol!mmunz@nosc.mil >> writes: >>>Why can't Apple just update PRODOS to support deleting of extended files.. >>>it seems like that would be the simplest solution. >>> ... >>Then again...maybe there isn't *room* for the code. 16K isn't just gobs of >>room for an OS. DESTROY isn't the only command that could conceivably be >>modified to deal with extended files--as soon as people could delete the >>things, they'd also want to be able to OPEN the forks & work with them, so >>most of the calls would need changes. > >Yes, I realize that there isn't room for resource stuff in the language card >banks of RAM (funny how it's still called a "language card", no?) Well, I offer a compromise: If ProDOS 8 is being run on a //gs, then there should be extra code loaded in and placed in upper memory (just use the memory manager) that would allow manipulation of forked files. I agree that there doesn't seem to be a pressing need for manipulating forked files on non //gs's (they should be in archives), but I like to do most of my housekeeping from ProDOS 8 (mainly because booting into the Finder just takes too long...while I can use Cat.Doctor in under 3 seconds from power-up). ProDOS 8, if run on a //gs, should support forked files (memory limitations wouldn't apply). For other //'s, a simple utility program would work well. But, don't expect it from Apple--they can't even provide us with ANY program to convert Mac disks. Oh yeah, did anyone here go to the Apple II developers convention in Kansas? Anything interesting happen? Kent Dickey kadickey@phoenix.Princeton.Edu kadickey@PUCC
delton@pro-carolina.UUCP (Don Elton) (07/30/89)
Network Comment: to #4299 by obsolete!SEWALL%UCONNVM.BITNET%cunyvm.cuny.edu
The way to handle forked files on a P8 machine is to get them converted to
AppleSingle format before you move them off a GS/OS environment. Once back in
the GS/OS environment you can make them back into regular forked files. There
aren't any utilities yet to do this conversion but if no one else does it I
suppose I'll do it in support of TIC/ECP16 etc.
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