neufeld@physics.utoronto.ca (Christopher Neufeld) (06/02/90)
Can anybody familiar with the vagaries of GS/OS tell me whether there might some time be a facility under ProDOS for forming logical links between directories, as the "ln" command in UNIX. This allows a single physical file to have directory entries in several different subdirectories on a disk, reducing the disk space necessary to have the convenience of keeping that file in more than one place on the disk. To provide a specific example, it might be handy to have such a facility for SoundSmith files, which are routinely kept in different subdirectories for each song. You don't really need eight identical copies of a given sound pattern. Other cases where it might be useful include the BASIC.SYSTEM file, and possibly the PRODOS file (at least Applied Engineering seems to think so in the design of the DataTerm disk). -- Christopher Neufeld....Just a graduate student | He's the kind of person neufeld@helios.physics.utoronto.ca | who'd follow you into a cneufeld@pro-generic.cts.com Ad astra! | revolving door and come "Don't edit reality for the sake of simplicity" | out first.
gwyn@smoke.BRL.MIL (Doug Gwyn) (06/04/90)
In article <1990Jun1.190541.2119@helios.physics.utoronto.ca> neufeld@physics.utoronto.ca (Christopher Neufeld) writes: > Can anybody familiar with the vagaries of GS/OS tell me whether there >might some time be a facility under ProDOS for forming logical links >between directories, as the "ln" command in UNIX. No, and it's because UNIX has essentially TWO filesystems, a flat one of "inodes" and a hierarchical one imposed on top of that using a special inode type as a directory (whose entries are just paired names and inode numbers). The ProDOS filesystem has only the hierarchy.
toddpw@tybalt.caltech.edu (Todd P. Whitesel) (06/04/90)
gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >In article <1990Jun1.190541.2119@helios.physics.utoronto.ca> neufeld@physics.utoronto.ca (Christopher Neufeld) writes: >> Can anybody familiar with the vagaries of GS/OS tell me whether there >>might some time be a facility under ProDOS for forming logical links >>between directories, as the "ln" command in UNIX. >No, and it's because UNIX has essentially TWO filesystems, a flat one >of "inodes" and a hierarchical one imposed on top of that using a >special inode type as a directory (whose entries are just paired names >and inode numbers). The ProDOS filesystem has only the hierarchy. So what? Soft links could be implemented as a new storage type, with the linked pathname stored in the key block. Prodos Pascal partitions and GS/OS forked files are implemented using new storage types also. Prodos 8 might barf on them but GS/OS programs shouldn't notice the difference. Todd Whitesel toddpw @ tybalt.caltech.edu
pnakada@oracle.com (Paul Nakada) (06/04/90)
In article <1990Jun4.014522.1843@laguna.ccsf.caltech.edu> toddpw@tybalt.caltech.edu (Todd P. Whitesel) writes: > > So what? Soft links could be implemented as a new storage type, with the linked > pathname stored in the key block. Prodos Pascal partitions and GS/OS forked > files are implemented using new storage types also. > Prodos 8 might barf on them but GS/OS programs shouldn't notice the difference. Todd, I think Doug was refering to a "hard link" in which just saving the path name wouldn't help. There would have to be some centralized index file that both could refer to, like an inode. -Paul Nakada -- Paul Nakada | Oracle Corporation | pnakada@oracle.com
neufeld@physics.utoronto.ca (Christopher Neufeld) (06/05/90)
OK, here's an idea of what I thought might work. I'm much more familiar with DOS3.3 than ProDOS, so maybe I'm making a poor assumption here. Create a new command "LINK <name>,<pathname>" and modify the DELETE command. I assume that ProDOS has an equivalent of the track/sector list and that it might have a few unused bits lying around somewhere. These bits would act as a link counter, set to one when the file is created. Now, the LINK command would create a new directory entry which would point to an existing track/sector list and would increment the link counter. The modified DELETE command would remove the directory entry and decrement the link counter. If the link counter is decremented to zero in this way, the file itself will be deleted and the physical disk space freed for other use. If DOS3.3 had subdirectories I could write a patch to it to do this quite easily. Is ProDOS so different that this couldn't be done? -- Christopher Neufeld....Just a graduate student | He's the kind of person neufeld@helios.physics.utoronto.ca | who'd follow you into a cneufeld@pro-generic.cts.com Ad astra! | revolving door and come "Don't edit reality for the sake of simplicity" | out first.
emm@iczer-1.UUCP (Edward M. Markowski) (06/06/90)
In article <PNAKADA.90Jun4095629@pnakada.oracle.com> pnakada@oracle.com (Paul Nakada) writes: > > Todd, I think Doug was refering to a "hard link" in which just saving >the path name wouldn't help. There would have to be some centralized >index file that both could refer to, like an inode. > I do not have a GS so I may be way off the mark here. Why can't a program just write a new directory entry that points to the same data blocks as the orginal? -- Edward M. Markowski -- iczer-1 Administrator ...the garage is flooded from the sprinkler. It also left a man's decapitated body, VOICE : (201) 478-6052 lying on the floor next to his own severed head. UUCP : ..!uunet!iczer-1!emm A head which at this time has no name.
toddpw@tybalt.caltech.edu (Todd P. Whitesel) (06/07/90)
pnakada@oracle.com (Paul Nakada) writes: > Todd, I think Doug was refering to a "hard link" in which just saving >the path name wouldn't help. There would have to be some centralized >index file that both could refer to, like an inode. I realize that; my point is that it would be very easy to implement soft links under ProDOS. For what many of us do soft links are fine and there is no need for hard links. Todd Whitesel toddpw @ tybalt.caltech.edu
animal@unix.SRI.COM (Chan Wilson) (06/11/90)
In article <318@iczer-1.UUCP> emm@iczer-1.UUCP (Edward M. Markowski) writes: [hard vs soft links nuked] > >Why can't a program just write a new directory entry >that points to the same data blocks as the orginal? What do you do when you delete one of the files? ProDOS as it stands will mark the blocks as free, leaving the other links out on a limb. You'd need to stuff a link counter in the file header someplace. Trouble is, there isn't much space. The only entries that you could bump would be the version or minimum-version fields. I think one of those is used to indicate upper/lowercase in the filename. To link subdirs, there's a little more freedom in the header, but the problem is they're all 'reserved' bytes. But the big problem, even if you do find space to stuff the link counter, is that you'd have to patch prodos and the prodos fst. This means you've got to decompile it, since Apple doesn't distribute source code, or entry points for this type of thing. I can't see any reason why such a mechanism couldn't be implimented, though.. >Edward M. Markowski -- iczer-1 Administrator > > ...the garage is flooded from the sprinkler. > It also left a man's decapitated body, >VOICE : (201) 478-6052 lying on the floor next to his own severed head. >UUCP : ..!uunet!iczer-1!emm A head which at this time has no name. ...I know its name... --Chan ................ Chan Wilson -- cwilson@nisc.sri.com <!> I don't speak for SRI. Janitor/Architect of comp.binaries.apple2 archive on wuarchive.wustl.edu "a2fx it!" ................
toddpw@tybalt.caltech.edu (Todd P. Whitesel) (06/13/90)
animal@unix.SRI.COM (Chan Wilson) writes: >You'd need to stuff a link counter in the file header someplace. Trouble >is, there isn't much space. The only entries that you could bump would >be the version or minimum-version fields. I think one of those is used >to indicate upper/lowercase in the filename. Both are used (you need 15 bits, one for each character). ProDOS should never have had upper-case only filenames in the first place, and when they wanted to add them they should have used version and min_version for what they were originally designed for, to indicate extra fields in the file entry. Prodos directories have fields for specifying the length and count of entries in each block and Apple is being stupid by hacking their spec and destroying the elegance it originally had. >But the big problem, even if you do find space to stuff the link counter, >is that you'd have to patch prodos and the prodos fst. This means you've >got to decompile it, since Apple doesn't distribute source code, or entry >points for this type of thing. Adding new fields to the entry can be done, but EVERY entry must be so extended because each directory header tells you how long each directory entry is and how many of them there are in each block. >I can't see any reason why such a mechanism couldn't be implimented, though.. I agree. Apple, however, has screwed up Prodos enough already, and I wonder who the hell they have maintaining prodos these days. Todd Whitesel toddpw @ tybalt.caltech.edu
reeder@reed.UUCP (Doug Reeder) (06/16/90)
Soft Links:
The major problem is that the file linked to can move out from
underneath your link if it is deleted or renamed, or any of its chain of
directories are renamed (or moved, for example by my MOVE.CMD, plug, plug).
For many applications, this is acceptable. Possibly, a bit in the access
byte could be allocated to signify that a file was linked to (actually, you
need a link counter), but its directory could still be renamed. A soft link
to a directory block and entry within it would solve the rename problem, but
deletion and new file creation could put a new file there, unless you had
that access bit to reserve the entry. Programs to clean up and rearrange
directories would have to be rewritten.
Hard Links:
The fundamental problem with hard links is that any time the file
information is changed, ALL the entries must reflect this. Under UNIX, the
relevant info is kept in the inode, which all links share. There is no room
in the ProDOS index blocks, and not all files have index blocks, anyhow.
My solution: two new storage types, the visible link, and the
pseudo-inode. The pseudo-inode would contain all the normal file
information, plus a link counter (probably in the filename area which would
not be needed by the pseudo-inode). The link would only contain the
information neccesary to find the pseudo-inode. This might take the form of
a block number and directory entry number, like the PARENT_POINTER and
PARENT_ENTRY in subdirectory headers. (Question: what happens when your
alphabetize a directory containing subdirectories and thus invalidate their
PARENT_ENTRYs?) Would all this fit in the space available for ProDOS?
Probably not.
--
Doug Reeder USENET: ...!tektronix!reed!reeder
from ARPA: tektronix!reed!reeder@berkeley.EDU BITNET: reeder@reed.BITNET
Things ain't what they used to be... and they never were.dlyons@Apple.COM (David A. Lyons) (06/27/90)
In article <1990Jun13.060715.3520@laguna.ccsf.caltech.edu> toddpw@tybalt.caltech.edu (Todd P. Whitesel) writes: >[...] Prodos >directories have fields for specifying the length and count of entries in each >block and Apple is being stupid by hacking their spec and destroying the >elegance it originally had. On the other hand, there is a fairly large amount of software in the world that does NOT work properly with non-$27 entry-lengths. >[...] Apple, however, has screwed up Prodos enough already, and I wonder who >the hell they have maintaining prodos these days. > >Todd Whitesel >toddpw @ tybalt.caltech.edu This tone is unnecessary and unjustified. Your constructive suggestions are welcome. Adding new storage types isn't my idea of "maintenance." ProDOS 8 is "full"--it has almost zero room to grow. Adding links would complicate OS operations more than I've seen anyone indicate here, and using utilities that do block-level access on a volume with links could easily leave the volume corrupted. -- David A. Lyons, Apple Computer, Inc. | DAL Systems Apple II Developer Technical Support | P.O. Box 875 America Online: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.
rond@pro-grouch.cts.com (Ron Dippold) (06/29/90)
In-Reply-To: message from dlyons@Apple.COM > This tone is unnecessary and unjustified. Your constructive suggestions > are welcome. I'm sure Todd will have a comment, but... How about if you knock around the guy who released a BASIC.SYSTEM that would do a BSAVE if you told it to do a BLOAD instead of reporting no free buffers? And does Apple really have any right to feel defensive if anyone criticizes them re: their treatment of the Apple II line? UUCP: crash!pro-grouch!rond ARPA: crash!pro-grouch!rond@nosc.mil INET: rond@pro-grouch.cts.com
shawn@marilyn.UUCP (Shawn P. Stanley) (07/10/90)
In article <2724.apple.net2@pro-grouch> rond@pro-grouch.cts.com (Ron Dippold) writes: >...And does Apple really have any right to feel defensive if anyone >criticizes them re: their treatment of the Apple II line? Apple is not one person, one entity. The people that do work on the GS and such are working for us, not against us. I don't think they'd be out of line feeling defensive about what you just said. -- Shawn P. Stanley shawn@marilyn.marilyn.mn.org bungia!marilyn!shawn {rosevax,crash}!orbit!marilyn!shawn