Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: net.micro.mac
Subject: Re: MAC filesystem vs UNIX filesystem
Message-ID: <8609232036.AA10451@cory.Berkeley.EDU>
Date: Tue, 23-Sep-86 16:36:17 EDT
Article-I.D.: cory.8609232036.AA10451
Posted: Tue Sep 23 16:36:17 1986
Date-Received: Tue, 23-Sep-86 23:18:24 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: University of California at Berkeley
Lines: 60


>Jim Budler writes:
>I hope you don't think that a Unix file is all physically contiguous.

	Unix files are physically contiguous with the exception that you can,
say, seek to position 11423444, do a write, and 11423444 bytes will actually
NOT be physically allocated... the intermediate data between X and 1142344,
when read, turns out to be zeros. (at least in BSD4.2)...  In fact, the
DBM database utilities use this extensively.

	What I do clarify, and I stated this in my last posting, is that
the nature of the filesystem itself is different (e.g. two forks instead of
a single file), and this has nothing to do with applications that utilize
the filesystem... whether it's for executables, object files, or what not.

	You can draw similarities, but you must realize that you're comparing
two different levels of implimentation.  You're comparing the MAC filesystem
implimentation (on the OS level) to one example of a UNIX file structure
(executables), which is on the application level.  Yes, the OS expects the
executable to be in a specific format, but it only applies to UNIX executables
that the OS will at some time try to run, not to anything else.

>I chose the executable because it is a common file type (not
>structure) roughly comparable to the macintosh. I could have chosen

	File structure.  If you start calling everything filetypes, then
what will you call *real* filetypes?  For instance, /dev/tty is a tty device,
not a normal file.  In some OS's, it goes deeper than that... files are 
specifically 'ascii' or 'baudot', 'executable', or whatever.
	
>They differ only in that the Macintosh pure data file has an
>extra *entry* in the directory for the resource fork. It may be empty
>and may be ignored. That data file can be accessed in exactly the
>same way as an Unix data file, namely fopen(), fget(), fput(), lseek(),
>fread(), fwrite().

	The difference is much deeper than that.  Since the MAC has 2 forks, any
utility that works on files (e.g. copy) must take that into account.  In the
same way UNIX utilities assume only one fork (cause there is only one fork).
I'm just pointing out that since the difference is on the OS level, it has
a larger set of ramifications than you might think.  My personal opinion is
that a single-fork ('normal' files) filesystem is easier to use and more
straight forward than Apple's two-fork scheme (recapping my last message, I
said that a two-fork scheme isn't useful unless you generalize it to an N
fork scheme, which IS useful).


>the printer and modem ports as ascii device drivers, use the default
>window size the compiler provides, you will get very unixlike applications
>which will perform like tasks. This, as I said in the other article, is
>the programmer's CHOICE. 

	And if you ignore the 'double data-path' of the MAC.  It is NOT
the programmers choice en toto... his program might be a utility of some 
sort, or have to deal with other common MAC data structures which utilize
multiple-forks.


			
						-Matt