Path: utzoo!utgpu!watserv1!watmath!att!bellcore!rutgers!usc!samsung!uunet!zephyr.ens.tek.com!tektronix!reed!reeder From: reeder@reed.UUCP (Doug Reeder) Newsgroups: comp.sys.apple2 Subject: Re: Logical file linking? Keywords: links Message-ID: <15088@reed.UUCP> Date: 16 Jun 90 09:54:56 GMT References: <1990Jun1.190541.2119@helios.physics.utoronto.ca> <13041@smoke.BRL.MIL> <1990Jun4.014522.1843@laguna.ccsf.caltech.edu> <318@iczer-1.UUCP> <13009@unix.SRI.COM> Reply-To: reeder@reed.UUCP (Doug Reeder) Organization: Tether Propulsion Division, Institute of Knowledge, Jinx Lines: 33 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.