dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/23/86)
>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
dwb@well.UUCP (David W. Berry) (09/25/86)
In article <8609232036.AA10451@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > >>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. Just to be the first of many to point this out, Unix files are rarely physically contigouus. Logically yes, physically definitely not. Various versions of UNIX go to varying degrees of effort to attempt to group the a file as contiguously as possible, but I know of no version which will guarantee the physical contiguity of a file. David -- David W. Berry dwb@well.uucp dwb@Delphi dwb@GEnie 293-0752@408.MaBell
jimb@amdcad.UUCP (Jim Budler) (09/25/86)
In article <8609232036.AA10451@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > >>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. > I guess this shows the quality of the opposition. A Unix file may be physically located anywhere on a disk. And any block in the disk may be anywhere on the disk. > 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, Choose your terms as you will, but in one section we were talking about OS file structures, and now you want to use the same word for distinguishing things which are NOT OS file structures. +--------------- Alright, damnit. A file structure on Berkeley Unix is a *logically* and NOT *physically* contiguous stream of bytes. A Mac a file structure is TWO *logically* seperate streams, each seperatelly containing a *logically* and NOT *physically* contiguous stream of bytes. +--------------- I never argued against the contention that the file structures were different. But that is the *only* mandatory OS difference a programmer has to honor. Period. +--------------- I will repeat again. THE ONLY WAY IN WHICH A PROGRAMMER MUST TREAT THE FILE SYSTEMS AS DIFFERENT WHEN WRITING A MAJORITY OF PROGRAMS IS TO ADD A FLAG VALUE INTO HIS OPEN(). You said this was a BOUND. This may be inconvenient, but hardly a bound. In addition, this flag need NOT be added when accessing only the data fork. +--------------- Thus a Unix program ported to a Macintosh may run in a Unix style, under a shell, with no modifications at all. Maybe not. But I can guarantee that it will not succeed or fail just because of the file system. +--------------- Bye. -- Jim Budler Advanced Micro Devices, Inc. (408) 749-5806 Usenet: {ucbvax,decwrl,ihnp4}!amdcad!jimb Compuserve: 72415,1200 Someday I'll learn not to fight with children.