cwilson@NISC.SRI.COM (Chan 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 [snip] >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. Hmm, I can think of a fairly easy way to make soft symbolic links. Make two more storage types, a type 6 and type 7 for argument sake. Type 6 would be a file that would have symbolic links attached to it; type 7 would be files that are linked to type 6. This is a nice, simple way to do it, since existing utilities would leave these types of files alone. It'd probably make things simpler if you devoted two more for type 5 files (data/resource files). Now, this is just casual thinking. On deeper thought, one realizes that you need to keep track of which files are linked to the master file, so you'd need a header block like type 5 files. This way, you can either delete all associated files (type 7) when you delete the master file (type 6), or you can change the storage type when all links are gone (back to existing type). Of course, I've contemplated just doing a primitive example of this, writing a hack to 'link' a file to another by just mucking with the pointers; problem here is that if you delete the master file, you're SOL.... Yup, this would require a new prodos fst, at least so these types of files would be usable on GS/OS. Tell me, how hard would it be to update Prodos 8 so it could know what to do with the type 5 files? --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. ................
rlw@ttardis.UUCP (Ron Wilson) (02/11/90)
In article <13033@fs2.NISC.SRI.COM>, cwilson@NISC.SRI.COM (Chan Wilson) writes: >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 >[snip] >>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. > >Hmm, I can think of a fairly easy way to make soft symbolic links. >Make two more storage types, a type 6 and type 7 for argument sake. >Type 6 would be a file that would have symbolic links attached to it; >type 7 would be files that are linked to type 6. This is a nice, simple >way to do it, since existing utilities would leave these types of files >alone. It'd probably make things simpler if you devoted two more for type >5 files (data/resource files). > >Now, this is just casual thinking. On deeper thought, one realizes >that you need to keep track of which files are linked to the master >file, so you'd need a header block like type 5 files. This way, you >can either delete all associated files (type 7) when you delete the >master file (type 6), or you can change the storage type when all >links are gone (back to existing type). >--Chan On Un*x system that have symbolic links, there is no special bookkeeping done. If the target of a symbolic link is deleted or is on a disk that is not currently mounted, the system simply says it that it can't open the file. In fact, many systems allow you to create the symbolic link even if the target file doesn't exist or if the target file's disk is not mounted. ALL of these systems permit you to delete the target file (indeed they don't even tell that there are any symbolic links). Many people may wonder why any one would actually design something that works this way. The reason is that symbolic links are inteded to only be a way of conveniently storing aliases for files in the file system. This may seem "lame," but having been a Un*x user and programmer for many years, I've come to appriciate both the convenience and space saving possiblities of this feature (and also "hardlinks" - but they really aren't ammenable to GS/OS or ProDOS).
farrier@Apple.COM (Cary Farrier) (02/11/90)
In article <13033@fs2.NISC.SRI.COM> cwilson@NISC.SRI.COM (Chan Wilson) writes: >Yup, this would require a new prodos fst, at least so these types of >files would be usable on GS/OS. Tell me, how hard would it be to >update Prodos 8 so it could know what to do with the type 5 files? Alot of P8 applications rely on things being at a fixed address in ProDOS 8 (they muck with it and patch things out, etc.). There also is not very much free room in P8 to do anything, so the task wouldn't be very easy or clean. > Chan Wilson -- cwilson@nisc.sri.com <or> radius!cwilson@apple.com -- +---------------------------------------+---------------------------------+ | 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. | +-------------------------------------------------------------------------+
aj0@sage.cc.purdue.edu (Eric Mulholland) (02/11/90)
In article <38520@apple.Apple.COM> farrier@Apple.COM (Cary Farrier) writes: > Alot of P8 applications rely on things being at a fixed address > in ProDOS 8 (they muck with it and patch things out, etc.). There > also is not very much free room in P8 to do anything, so the > task wouldn't be very easy or clean. If programs are playing around in Prodos 8 like that, it's the author's problem and not Apple's. I remember when Prodos first came, Apple said it would not hesitate to move code around when Prodos is recompiled. They learnned (hopefully) from the dos 3.3 days. I can buy the reasons of not enough space in Prodos to added the code. But the problems with P8 utilities being allowed to read forked (data fork) files, I believe gives more problems than solving them, because the user is not always aware that he is maliplating an extended file. While I'm speaking of Prodos 8, why is it when Prodos first came out, that file names did not support true lower case letters then? I know with dos 3.3, you could name files using lower case, but prodos didn't allow that. Does it have to deal with SOS somehow? If so, why didn't SOS support lower case? The excuse that the standard //+ does not display lower case is not good enough, since dos 3.3 allowed it. -- ____ Y_,_|[]| Eric Mulholland {|_|_|__| aj0@sage.cc.purdue.edu //oo--OO ...!pur-ee!sage.cc!aj0