Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!spool.mu.edu!agate!agate!dpassage
From: dpassage@soda.berkeley.edu (David G. Paschich)
Newsgroups: comp.unix.wizards
Subject: Re: file attributes
Message-ID: <DPASSAGE.91Jun23021308@soda.berkeley.edu>
Date: 23 Jun 91 10:13:08 GMT
Article-I.D.: soda.DPASSAGE.91Jun23021308
References: <1743@sranha.sra.co.jp>
	<1991Jun20.021749.12011@gpu.utcs.utoronto.ca> <20438@alice.att.com>
	<16508@smoke.brl.mil>
Sender: usenet@agate.berkeley.edu (USENET Administrator)
Organization: UC Berkeley's Open Computing Facility
Lines: 29
In-Reply-To: gwyn@smoke.brl.mil's message of 22 Jun 91 23: 23:30 GMT

In article <16508@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
   In article <20438@alice.att.com> andrew@alice.att.com (Andrew Hume) writes:
   >For example, how can I access resources from a Macintosh file acessed 
   >through a network file system? This is a serious problem and worthy of at 
   >least some thought.

   As little as possible, however.  <pathname>/resource and <pathname>/data
   immediately spring to mind as solutions for the "forked file" problem that
   Apple invented.

A/UX, Apple's Unix variant, solves this by making the Mac file MacFoo
appear in the Unix tree as "MacFoo" for the resource fork and
"*MacFoo" (yes, *) for the data fork.

You can also always store Mac files in MacBinary format, a standard
format which encodes all the file typing and like information in the
front of the file.

All this discussion of making Unix work like a Mac seems silly.  If
you want a Mac, then buy a Mac.  It would seem to me to be more
productive in the long run to come up with a new GUI paradigm to deal
with Unix's generality and power, rather than to retrofit an
established interface to fit the Unix semantics.


--
David G. Paschich	Open Computing Facility		UC Berkeley
dpassage@ocf.berkeley.edu
Go Colorado Rockies -- Opening Day, Mile High Statium, April 1991