nicholaA@moravian.EDU (Andy Nicholas) (05/13/89)
Just thought I'd add a little something to what Larry Virden was saying -- Current versions of ShrinkIT, because they run under P8, will not handle forked files. At all. The GS/OS version of ShrinkIt will handle and archive forked files properly. Previous versions of shrinkit, upon encountering an archived forked file, will just skip the resource fork and extract only the data fork. andy
jazzman@claris.com (Sydney R. Polk) (05/13/89)
From article <8905121810.AA13722@batman.moravian.edu>, by nicholaA@moravian.EDU (Andy Nicholas): > > Just thought I'd add a little something to what Larry Virden was saying -- > Current versions of ShrinkIT, because they run under P8, will not handle > forked files. At all. > > The GS/OS version of ShrinkIt will handle and archive forked files properly. > Previous versions of shrinkit, upon encountering an archived forked file, > will just skip the resource fork and extract only the data fork. > > andy Actually, all prodos 8 programs will ignore such files, as any attempted access will return an error ("unsupported file type") -- 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.
lwv@n8emr.UUCP (Larry W. Virden) (05/14/89)
I dont understand how ProSel's Mr Fixit - a prodos 8 file mangler - can handle forked files if 'it is impossible' for prodos 8 to handle the forked files? Also, I think this is a bad precedence - having a file type that prodos 8 programs cannot at least copy, etc. Is there anything being done about this? -- Larry W. Virden 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 n8emr!lwv@cis.ohio-state.edu (Internet) 75046,606 (CIS) ; LVirden (ALPE) ; osu-cis!n8emr!lwv (UUCP) The world's not inherited from our parents, but borrowed from our children.
delton@pro-carolina.UUCP (Don Elton) (05/14/89)
Network Comment: to #2603 by obsolete!n8emr!lwv%tut.cis.ohio-state.edu
A ProDOS 8 program can deal with forked files but not via standard
READ/OPEN/WRITE calls. It would have to use direct block access to find the
data via the indexes etc and Mr.Fixit could do this.
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-4111blochowi@cat24.CS.WISC.EDU (Jason Blochowiak) (05/15/89)
In article <1091@n8emr.UUCP> lwv@n8emr.UUCP (Larry W. Virden) writes: > >I dont understand how ProSel's Mr Fixit - a prodos 8 file mangler - can handle >forked files if 'it is impossible' for prodos 8 to handle the forked files? It goes around ProDOS 8 to get to the files, or at least it seems like it does, as it'd be nearly impossible to do what it does without bypassing ProDOS 8's file handling. I do imagine it uses the block device support of ProDOS, tho' :) >Also, I think this is a bad precedence - having a file type that prodos 8 >programs cannot at least copy, etc. Is there anything being done about this? I presume you mean precedent? Anyways, I think that it'd be mighty difficult to keep downwards compatibility forever - upwards is enough of a chore... By the way, this already happened to a certain extent when ProDOS 16 started supporting more partitions on a hard drive, which I think happened as of GS/OS. I suppose it'd be possible to fit resource fork support into ProDOS 8, but I'd be willing to bet that it'd be one hell of a squeeze - remember, GS/OS' restrictions on where it fits into memory are much looser than ProDOS 8's. >Larry W. Virden 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 ------------------------------------------------------------------------------ Jason Blochowiak (blochowi@garfield.cs.wisc.edu) "Not your average iconoclast..." ------------------------------------------------------------------------------
mattd@Apple.COM (Matt Deatherage) (05/15/89)
In article <1091@n8emr.UUCP> lwv@n8emr.UUCP (Larry W. Virden) writes: > >I dont understand how ProSel's Mr Fixit - a prodos 8 file mangler - can handle >forked files if 'it is impossible' for prodos 8 to handle the forked files? > >Also, I think this is a bad precedence - having a file type that prodos 8 >programs cannot at least copy, etc. Is there anything being done about this? > As Jason later explained, it's not a file type, it's a storage type. And there's been one out there for at least four years that ProDOS 8 can't read - the Pascal area on ProFile drives created by the Pascal ProFile Manager. Of course the files are accessible at the block level, but this is a very bad thing to do by default because a) *most* 8-bit users don't want, don't care about and don't need extended files; creating them on their disks (like when unpacking a IIgs program) just causes problems for the vast majority of programs that can't deal with them, and b) it automatically makes the program not work over AppleShare, which is a bigger deal than many people would like to think. The recommended way for P8 programs, specifically disk packers/unpackers, to deal with extended files is documented (already!) in the File Type Notes for File Types $E0, auxiliary types $0001 - $0003. Those give formats developed by Apple for extended files in foriegn file systems, which applies to GS/OS Extended files on ProDOS disks when running under ProDOS 8. (They also apply to UNIX - a good AppleSingle/AppleDouble translator could make passing Apple II and Macintosh files around the network a whole lot easier.) By using these formats that convert forked files into one or two non-forked files, the user can do what he wants with each fork. IIgs users can run an almost-trivial utility to turn them back into forked files (or they can run GS/OS versions of ShrinkIT, when available, that will be able to read the files directly). The point is some extensive thought has gone into this before the question even came up on the net. Read the File Type Notes in question for more information. >-- >Larry W. Virden 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 >n8emr!lwv@cis.ohio-state.edu (Internet) >75046,606 (CIS) ; LVirden (ALPE) ; osu-cis!n8emr!lwv (UUCP) >The world's not inherited from our parents, but borrowed from our children. ----------------------------------------------------------------------------- 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." -----------------------------------------------------------------------------
lwv@n8emr.UUCP (Larry W. Virden) (05/16/89)
Thanks for the pointers. The reason that forked files and prodos 8 are important to me is that I typically use a P8 based shell to do all my work. This means that I now cannot just arbitrarily unpack archives, since there is no guarantee that the files created will be able to be moved or copied within my environment. How depressing! -- Larry W. Virden 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 n8emr!lwv@cis.ohio-state.edu (Internet) 75046,606 (CIS) ; LVirden (ALPE) ; osu-cis!n8emr!lwv (UUCP) The world's not inherited from our parents, but borrowed from our children.
bh1e+@ANDREW.CMU.EDU (Brendan Gallagher Hoar) (07/14/89)
--- On the subject of extended files... Not being a programmer of any real talent, I haven't ever written any system programs (or anything that makes Apple ProDOS 8 MLI calls)... so... assuming that deleting a file is done by issuing the MLI DESTROY call (correct so far?), programs that follow Apple's standards for working with ProDOS-GS/OS disks at the file level should be able to delete a file by doing so. Shouldn't the ProDOS 8 released with GS/OS 5.0 support DESTROYING extended files? If it doesn't, it would seem to me that Apple isn't supporting the extended file format as a PRODOS extension (it is used thru the ProDOS FST, isn't it?), but merely as a GS/OS extension to ProDOS. And if they are doing that, why not just totally rewrite it, since it makes it incompatible? Or am I just severly confused (and definitely confusing)? :) bh1e+@andrew.cmu.edu
dlyons@Apple.COM (David Lyons) (07/15/89)
In article <IYjFyJW00WB7IIXVxW@andrew.cmu.edu> bh1e+@ANDREW.CMU.EDU (Brendan Gallagher Hoar) writes: [ ProDOS 8 really ought to be able to DESTROY extended files ] >If it doesn't, it would seem to me that Apple isn't supporting the extended >file format as a PRODOS extension (it is used thru the ProDOS FST, isn't it?), >but merely as a GS/OS extension to ProDOS. And if they are doing that, why >not just totally rewrite it, since it makes it incompatible? I'm having a lot of trouble following the logic there. Why would you want to throw away all the existing compatibility? Not everybody likes the idea of resource forks--but they exist. Given that extended files exist, would you prefer *not* to be able to create them on ProDOS disks? That would mean you'd have to have some *other* kind of volume that you'd normally use with GS/OS, and ProDOS 8 wouldn't be able to get at any files on that volume at all, even if they didn't have resource forks. --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.