ehoogerbeets@rose.waterloo.edu (Edwin Hoogerbeets) (07/09/89)
Someone whose name I accidentally deleted wrote:
% First, you don't need a NewExNext. Just have ExNext check the magic
% link bit when it comes to a link. If the bit is on (set by the user),
% it just hands back the link block, which contains nothing but the file
% name and the name of the file it's a link to. If the bit is off (which
% it should be for all current binaries), it gets a FileInfoBlock for
% the file the link points to, and then plugs the name from the link FIB
% into the new one, and hands that back to the user.
I have been looking at the FileInfoBlock definition in the header
files, and I noticed that there is a "padding" field, that I assume
no one currently uses or looks at it.
Perhaps a short word of the padding can be allocated for use as a
"link" flag. When doing an Examine() or and ExNext(), this field will
tell whether or not the lock passed to it is a lock on a soft link
file or a real file.
A new flag will be needed for Lock() to ask for a lock on the link
file instead of the file it links to.
/* something like: */
#define ACCESS_LINK -3L
Then directory manipulation programs would do:
BPTR lock = Lock("foo",ACCESS_LINK & ACCESS_READ);
/* & is used because of the screwy #defines of ACCESS_READ and _WRITE */
This might be necessary if a copy program wants to clone the directory
exactly, up to and including copying the link files. Note that leaving
out the ACCESS_LINK flag would merely get a lock on the linked-to file,
and the copy program would happily chug along copying the actual file
instead of the link to it.
Presumably, Open() would require a similar flag.
% Remember, you're introducing a new file type into the system. Every
% program that looks at a files type must be made to deal with this
% type. You also have to make sure that the default behavior doesn't
% make existing programs die in strange ways.
Actually, a link should resolve to either a file or directory if you do
not explicitly say otherwise, so there is effectively no new type. If
the dos.library routines implemented links invisibly, then old programs
should notice no difference.
This is the important part: the only way to work with a link file would
be if you know they are there, and you explicitly ask for them.
These are the changes needed for symlinks to be implemented totally in
dos.library as I see it:
Examine(): This must be changed to use the padding as suggested
above for the link file flag.
ExNext(): This must be changed to follow links and return the
FileInfoBlock of the file that is linked-to. If the "dereferenced"
file is not found, return an ERROR_OBJECT_NOT_FOUND as if the link
file had some problem itself.
DeleteFile(): I think this does not have to be changed. If you delete a
link file, you delete it. Period. If you want to delete the linked to
file, then delete it instead of the link.
Lock(): Try to [recursively?] get a lock on some file by following
link files. A lock on the destination is indistinguishable from
locking the linked-to file directly. The link files themselves are
not affected or locked. Add a flag to lock the link file directly.
If the lock is Examined, the FileInfoBlock of the actual locked file
(not the link file) should be returned. Hopefully, no one assumes
that a Lock() of "foo" followed by an Examine() of the lock returns
"foo" in the fib_FileName field. This is the one area that may break
something somewhere.
Open(): Do similar things as Lock(), and only open the final
linked-to file. Add special flag for accessing the link file
directly.
Read(), Write(), Close(), CreateDir(), DupLock(), Input(), Info(),
IsInteractive(), Output(), ParentDir(), Rename(), Seek(), UnLock(),
WaitForChar(), CreateProc(), Delay(), DeviceProc(), Exit(), Execute(),
and UnloadSeg() need not be changed.
IoErr() would have to be updated to take care of link errors, etc.
LoadSeg(): This must be changed to follow links as well. Hopefully,
if LoadSeg() is implemented internally using Open() and Lock(), this
will happen automatically.
SetComment(), SetProtection(), and DateStamp(): I think the link file
should have separate file attributes from the linked-to file. Thus, the
name of the file linked to should be stored in the file's data blocks,
and not in the comment field, as suggested before. In this case, these
functions do not need to be changed.
Some function should be added to dos.library:
Async versions of the important functions that implement links.
(eg: AsyncOpen()) If there are async versions, then there would be no
excuse to send your own dos packets for those particular actions, and
the dos.library will still be able to handle links.
A Link() call should be added to create a link file.
And then there are the "while you're at it" changes:
Add a SetDate().
Change LoadSeg() to ignore hunks it does not understand. This way
people can put in their own hunks for symbolic debugging, or stack
specification, in an upwards compatible way.
Add an optional hunk_stack or hunk_environment to the load file
structure to be able to specify how much stack space or other
environment needs the program will have.
% >From: jesup@cbmvax.UUCP (Randell Jesup)
% There are two obvious ways to implement links: one with files with
% a link bit set, the other using a couple of new packets to deal with
% links and opening files. Both will affect asych packet io people (if they
% Lock/Open using asych - Read/Write/etc won't be affected); one requires
% no modification to filesystems (and therefor can be used on OFS floppies,
% over NFS, etc immediately), the other is a bit more robust in dealing
% with asynch IO and old dir/delete/etc programs.
% Comments?
% >From: jesup@cbmvax.UUCP (Randell Jesup)
% Currently, Amiga softlinks will work like Unix softlinks. Most
% probable implementation is as a file with the "softlink" protection bit
% set,
% and the file containing the string for the link, unless I can figure a way
% to worm it into the header (for short strings). The nice thing about this
% is that existing filesystems will magically support softlinks with no new
% packets, at the expense slightly slower opens/locks, since the fileheader
% must be retrieved to check the bits. However, the file header block almost
% certainly will be cached at that point, since it's needed to lock the file.
% (The Dos manual lies when it says locks are much cheaper than opens. :-)
% Opinions? (ducking from the avalanche of c.s.a.t messages :-)
Consider that many programs do not honour the protection bits, and
this means an "l" bit would not be guaranteed to be set for a link
file (thought it should be anyways). I can name some programs that
clobber them, and it has bitten me before.
Perhaps some other method can be found for storing the fact that a link
file is indeed a link file. How about using a bit in the spare space in
the file header block at SIZE-50? That would require a FS change,
but it would not break old FS disks, would it?
As a side note: how about bit 9 in the protection bits for the link
bit?
Amigans greeting each other:
"lhsparwed to you!"
"Excuse me?"
(We need more vowels, people. That's totally unpronouncable unless
you're a Klingon or a Czech 8-)
Edwin