rnf@shumv1.uucp (Rick Fincher) (02/01/90)
In article <9001311847.AA29777@apple.com> NOSES@DBNINF5.BITNET (Achim Patzner) writes: > >Have the people who are crying for a Mac-HFS FST ever asked themselves what >they need that FST for? Sometimes I wonder... >What would a FST do for you? It would enable you to transfer files from Mac >volumes to GS/OS volumes... The same thing could be done by writing a It would enable IIgs's to coexist in a Mac office environment, particularly if AppleWorks is developed for the Mac or translators are developed that would allow the GS to read Mac data files. This could help the whole II family. It would also let GS users in the university environment get along much more easily than they do now. >The Hirarchical File System doesn't provide exciting features that the GS/OS >implementation of ProDOS doesn't have (correct me if I'm wrong). I think a What HFS does provide that ProDos doesn't is hard drive volumes larger than 32 megs. This is becomming an issue. If you want to use the IIgs as a low cost server you need access to bigger disk volumes. Rick Fincher rnf@shumv1.ncsu.edu
cwilson@NISC.SRI.COM (Chan Wilson) (02/03/90)
In article <9001311847.AA29777@apple.com> NOSES@DBNINF5.BITNET (Achim Patzner) writes: [...hfs fst...] >volumes to GS/OS volumes... The same thing could be done by writing a >program like the Mac's AFE utility as GS/OS is able to read those volumes at >the block level. All that would have to be done was reading some Mac manuals >about the structure of a Mac volume and writing a short utility that does the >transfer. That doesn't sound too difficult to me. (No, *I* won't do it; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Hah hah hee hee... I have yet to figure out whether the creators of HFS were insane or brilliant. 'B-Trees', for god's sake. Try deciphering one of those. You can't even tell what files are hidden in subdirectories, because you can't even _find_ the subdirectory to start with. And I haven't found any technotes that deal with this topic... (hey Cary, remember this topic? ) Gosh, for all I know, HFS is tame. Haven't the foggiest idea how Unix handles things, espec. linked files and the like.. (now _there's_ a feature I'd like to see. maybe. ) >Achim >(Noses@DBNINF5.bitnet; if that won't work, try {anything}!unido!bnu!patzner) --Chan ................ Chan Wilson -- cwilson@nisc.sri.com <or> radius!cwilson@apple.com Janitor/Architect of comp.binaries.apple2 archive on wuarchive.wustl.edu I don't speak for SRI, someone else does. ................
rnf@shumv1.uucp (Rick Fincher) (02/04/90)
In article <12775@fs2.NISC.SRI.COM> cwilson@NISC.SRI.COM (Chan Wilson) writes: >In article <9001311847.AA29777@apple.com> NOSES@DBNINF5.BITNET (Achim Patzner) writes: >[...hfs fst...] >>volumes to GS/OS volumes... The same thing could be done by writing a >>program like the Mac's AFE utility as GS/OS is able to read those volumes at >>the block level. All that would have to be done was reading some Mac manuals >>about the structure of a Mac volume and writing a short utility that does the >>transfer. That doesn't sound too difficult to me. (No, *I* won't do it; > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >Hah hah hee hee... > >I have yet to figure out whether the creators of HFS were insane or brilliant. >'B-Trees', for god's sake. Try deciphering one of those. You can't even >tell what files are hidden in subdirectories, because you can't even >_find_ the subdirectory to start with. And I haven't found any technotes >that deal with this topic... (hey Cary, remember this topic? ) > Inside Macintosh vol 4 and 5 have a detailed discussion of the HFS B-Trees. Trees are used because of their efficiency in terms of searching. They are nothing exotic, they've been used in Computer Science for a while. They just take a little studying. Rick Fincher rnf@shumv1.ncsu.edu
cwilson@NISC.SRI.COM (Chan Wilson) (02/04/90)
In article <1990Feb3.175459.11564@ncsuvx.ncsu.edu> rnf@shumv1.ncsu.edu (Rick Fincher) writes: >In article <12775@fs2.NISC.SRI.COM> cwilson@NISC.SRI.COM (Chan Wilson) writes: >>In article <9001311847.AA29777@apple.com> NOSES@DBNINF5.BITNET (Achim Patzner) writes: >>[...hfs fst...] >Inside Macintosh vol 4 and 5 have a detailed discussion of the HFS B-Trees. >Trees are used because of their efficiency in terms of searching. They are >nothing exotic, they've been used in Computer Science for a while. They >just take a little studying. Ah, okay. I'll check those out. But efficiency in terms of searching? Why does it take 2 1/2 minutes to open a system folder with ~130 items in it? (on a IIx w/8 megs) Gosh, talk about getting tired of watch cursors... >Rick Fincher >rnf@shumv1.ncsu.edu --Chan ................ Chan Wilson -- cwilson@nisc.sri.com <or> radius!cwilson@apple.com Janitor/Architect of comp.binaries.apple2 archive on wuarchive.wustl.edu I don't speak for SRI, someone else does. ................
jason@madnix.UUCP (Jason Blochowiak) (02/06/90)
In article <12775@fs2.NISC.SRI.COM> cwilson@NISC.SRI.COM (Chan Wilson) writes: >In article <9001311847.AA29777@apple.com> NOSES@DBNINF5.BITNET (Achim Patzner) writes: >[...hfs fst...] >>volumes to GS/OS volumes... The same thing could be done by writing a >>program like the Mac's AFE utility as GS/OS is able to read those volumes at >>the block level. All that would have to be done was reading some Mac manuals >>about the structure of a Mac volume and writing a short utility that does the >>transfer. That doesn't sound too difficult to me. (No, *I* won't do it; > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >Hah hah hee hee... Is it just me, or do people always say "It's not that bad, really, but hell if _I'm_ going to do it."? Btw, saying that a one-shot translator would be as useful in comparison with a HFS FST is like saying that punch cards do just as good a job as hard disks. Well, yeah, they do the same thing (store data), just not quite as conveniently, or quickly (in terms of direct response to the user). Kinda like not having DA's around (on a single-tasking machine - I personally do prefer "xcalc &", but that's another issue entirely) all the time - imagine having to exit your current application, and then launch your calculator program, figure something out, then... Enough with the analogies, eh? >I have yet to figure out whether the creators of HFS were insane or brilliant. >'B-Trees', for god's sake. Try deciphering one of those. You can't even >tell what files are hidden in subdirectories, because you can't even >_find_ the subdirectory to start with. And I haven't found any technotes >that deal with this topic... (hey Cary, remember this topic? ) Yes, this is unfortunate - I'd really like a Mac TN describing the format myself, if for no other reason than to prove that all moderately good programmers are inherently insane, which is to say nothing of the great programmers... >Gosh, for all I know, HFS is tame. Haven't the foggiest idea how Unix handles >things, espec. linked files and the like.. (now _there's_ a feature I'd like >to see. maybe. ) I've yet to delve into the depths of HFS (aww, come on, B-Trees aren't all that bad, at least if you're just reading them) but the unix filesystems I've seen are fairly simple. There are a fixed number of i-nodes (either index or info nodes, forget which), and each file gets one. The directory entries reference the file by its i-node. Each i-node keeps track of where the file is sitting on the media (by using something vaguely like what ProDOS does, although unix's filesystem seems somewhat better suited to massive changes in file size), how many references there are to it (so that when all of the references have been "unlinked", the file itself gets nuked), access privs, and some other gunk. Of course, this is a rather light treatment for a filesystem, but this is comp.sys.apple, after all. Well, come to think of it, I would like a unix-like filesystem for the //gs - there've been a large number of times when I wished that I could do something kinda neat like "ln -s ...". Someone's .sig said that symbolic links are the GOTO's of filesystems - although I tend to avoid them when possible, I'm not a GOTO-phobe. >>Achim >>(Noses@DBNINF5.bitnet; if that won't work, try {anything}!unido!bnu!patzner) > Chan Wilson -- cwilson@nisc.sri.com <or> radius!cwilson@apple.com >Janitor/Architect of comp.binaries.apple2 archive on wuarchive.wustl.edu Congratulations, you've made it through "Jason's incoherent _I've been programming for 14 hours, and I'm not tired yet. Really._ ramblings", part MCXM (?). -- Jason Blochowiak - jason@madnix.UUCP or, try: astroatc!nicmad!madnix!jason@spool.cs.wisc.edu "Education, like neurosis, begins at home." - Milton R. Saperstein
jm7e+@ANDREW.CMU.EDU ("Jeremy G. Mereness") (02/09/90)
I have only one comment about the usefulness of a MacHFS FST: I have had many people approach me who have GS's at home and use Macs at work. They want to edit their MS Word stuff on their GS at home. They looks the same... the formatting looks similar on the screen... why wouldn't this be possible like MSWord reading MacWrite files? I have to tell them no, and explain complicated things like HFS and GS/OS, which makes them ask for Excedrin. If the FST was in existence, it would be used to port data back and forth from Mac to GS and back. Marketing types would rather be able to say that this is impossible, you should buy a MacSE for your home, which is the only reason I can see for why the FST is still vapor. I WOULD write it myself, but I am on another project currently, and the means of writing FST's under GS/OS has not been released. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |Jeremy Mereness | Support | Ye Olde Disclaimer: | |jm7e+@andrew.cmu.edu (internet) | Free | The above represent my| |r746jm7e@cmccvb (Vax... bitnet) | Software | opinions, alone. | |staff/student@Carnegie Mellon U. | | Ya Gotta Love It. | ---------------------------------------------------------------------------
rlw@ttardis.UUCP (Ron Wilson) (02/09/90)
In article <1101@madnix.UUCP>, jason@madnix.UUCP (Jason Blochowiak) writes: > > I've yet to delve into the depths of HFS (aww, come on, B-Trees aren't >all that bad, at least if you're just reading them) but the unix filesystems >I've seen are fairly simple. There are a fixed number of i-nodes (either >index or info nodes, forget which), and each file gets one. The directory >entries reference the file by its i-node. Each i-node keeps track of where >the file is sitting on the media (by using something vaguely like what >ProDOS does, although unix's filesystem seems somewhat better suited to >massive changes in file size), how many references there are to it (so that >when all of the references have been "unlinked", the file itself gets nuked), >access privs, and some other gunk. Of course, this is a rather light >treatment for a filesystem, but this is comp.sys.apple, after all. Well, come >to think of it, I would like a unix-like filesystem for the //gs - there've >been a large number of times when I wished that I could do something kinda >neat like "ln -s ...". Someone's .sig said that symbolic links are the >GOTO's of filesystems - although I tend to avoid them when possible, I'm not >a GOTO-phobe. >-- > Jason Blochowiak - jason@madnix.UUCP A symbolic link is a directory entry that either: a) contains the path name of the target file or b) points to a file with one data block, which, in turn, contains the pathname of the target file Method b could easily be implemented on ProDOS and GS/OS. Method a would require larger entries in directories (or better yet, variable length entries - could also allow longer file names to be used). For ProDOS and GS/OS, method b is propably the best way to implement symbolic links. (To the GS/OS and ProDOS development teems: How about doing this? (symbolic links)) Unix file systems also have what are called "hard links" - these are the "normal" Unix directory entries - ie: the directory entry contains the inode number of the file. This is something that would require an Unix FST to do on GS/OS.
farrier@Apple.COM (Cary Farrier) (02/09/90)
In article <1990Feb3.175459.11564@ncsuvx.ncsu.edu> rnf@shumv1.ncsu.edu (Rick Fincher) writes: >Inside Macintosh vol 4 and 5 have a detailed discussion of the HFS B-Trees. >Trees are used because of their efficiency in terms of searching. They are >nothing exotic, they've been used in Computer Science for a while. They >just take a little studying. Not really. Vols 4 and 5 give a general description of a B*-Tree (note that these are *not* B-Trees, folks!), but nothing very useful. They also don't give very much information on the HFS file system. >Rick Fincher >rnf@shumv1.ncsu.edu Cary Farrier -- +---------------------------------------+---------------------------------+ | Cary Farrier | Internet : farrier@apple.com | | Apple II Systems Software Engineering | UUCP : apple!farrier | | Apple Computer, Inc. | Fax : (408) 974-1704 | | 20525 Mariani Ave. | AppleLink : FARRIER | | Cupertino, CA 95014 | or farrier@applelink.apple.com | +---------------------------------------+---------------------------------+ | I don't speak for Apple Computer, our products do. | +-------------------------------------------------------------------------+
farrier@Apple.COM (Cary Farrier) (02/09/90)
In article <2463@ttardis.UUCP> rlw@ttardis.UUCP (Ron Wilson) writes: >A symbolic link is a directory entry that either: > a) contains the path name of the target file >or b) points to a file with one data block, which, in turn, contains > the pathname of the target file > >Method b could easily be implemented on ProDOS and GS/OS. Method a would >require larger entries in directories (or better yet, variable length entries - >could also allow longer file names to be used). For ProDOS and GS/OS, method b >is propably the best way to implement symbolic links. > >(To the GS/OS and ProDOS development teems: How about doing this? (symbolic >links)) > >Unix file systems also have what are called "hard links" - these are the >"normal" Unix directory entries - ie: the directory entry contains the inode >number of the file. This is something that would require an Unix FST to do >on GS/OS. Option A would require application level knowledge of the soft links. Not a very nice way to do things, especially since none of the exisiting applications would work with it. I don't see why A would require longer names, or even variable length names. Option B would require an FST to implement this, and is not as easy as you might think. The thing that really makes soft links useable is that under UNIX you don't swap disks at your leisure. Under GS/OS, you would have to either limit soft links to the same volume, or you would end up doing alot of disk swapping if you don't have a hard drive (or multiple hds). They are a nice idea, but IMHO probably not worth the time to implement. -- +---------------------------------------+---------------------------------+ | Cary Farrier | Internet : farrier@apple.com | | Apple II Systems Software Engineering | UUCP : apple!farrier | | Apple Computer, Inc. | Fax : (408) 974-1704 | | 20525 Mariani Ave. | AppleLink : FARRIER | | Cupertino, CA 95014 | or farrier@applelink.apple.com | +---------------------------------------+---------------------------------+ | I don't speak for Apple Computer, our products do. | +-------------------------------------------------------------------------+
rlw@ttardis.UUCP (Ron Wilson) (02/10/90)
In article <38482@apple.Apple.COM>, farrier@Apple.COM (Cary Farrier) writes: > >In article <2463@ttardis.UUCP> rlw@ttardis.UUCP (Ron Wilson) writes: >>A symbolic link is a directory entry that either: >> a) contains the path name of the target file >>or b) points to a file with one data block, which, in turn, contains >> the pathname of the target file >> >>Method b could easily be implemented on ProDOS and GS/OS. Method a would >>require larger entries in directories (or better yet, variable length entries - >>could also allow longer file names to be used). For ProDOS and GS/OS, method b >>is propably the best way to implement symbolic links. >> >>(To the GS/OS and ProDOS development teems: How about doing this? (symbolic >>links)) ..... > >Option B would require an FST to implement this, and is not as easy as you >might think. .... >-- >+---------------------------------------+---------------------------------+ >| Cary Farrier | Internet : farrier@apple.com | Yes, I know that either a new FST or a new ProDOS FST would be required for either method of softlinks. Is the documentation for writing FSTs available?
farrier@Apple.COM (Cary Farrier) (02/11/90)
In article <2467@ttardis.UUCP> rlw@ttardis.UUCP (Ron Wilson) writes: > >Is the documentation for writing FSTs available? Only internally at Apple. Apple's view is that all FST's will be written in-house. Folks: Let's not let my quoting of the party line spark a whole discussion on Apple not giving out this information, ok? I know that most of you out there don't agree with it, and so does every other Apple employee that reads this newsgroup, and every Apple employee that works on the System Disk software. -- +---------------------------------------+---------------------------------+ | Cary Farrier | Internet : farrier@apple.com | | Apple II Systems Software Engineering | UUCP : apple!farrier | | Apple Computer, Inc. | Fax : (408) 974-1704 | | 20525 Mariani Ave. | AppleLink : FARRIER | | Cupertino, CA 95014 | or farrier@applelink.apple.com | +---------------------------------------+---------------------------------+ | I don't speak for Apple Computer, our products do. | +-------------------------------------------------------------------------+