Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!uwvax!puff!cat24!blochowi
From: blochowi@cat24.CS.WISC.EDU (Jason Blochowiak)
Newsgroups: comp.sys.apple
Subject: Re: forked files...
Message-ID: <2780@puff.cs.wisc.edu>
Date: 14 May 89 17:55:08 GMT
References: <8905121810.AA13722@batman.moravian.edu> <10142@claris.com> <1091@n8emr.UUCP>
Sender: news@puff.cs.wisc.edu
Reply-To: blochowi@cat24.CS.WISC.EDU (Jason Blochowiak)
Organization: U of Wisconsin CS Dept
Lines: 25

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..."
 ------------------------------------------------------------------------------