Re: VSTa status

[larz@world.std.com (Mike A Larson) writes:]

>What changes need to be made to the filesystem servers to support
>symbolic links? The reason I ask is because I'm about to add
>support for the Rock Ridge Extensions to the CDROM server and I'd
>like to coordinate the symbolic link part of this work with what you've
>done. Thanks.

Not too much. I stole the "hidden" attribute bit to represent the file
being a symlink. So you need to map that bit into filetype "symlink", add
some code so the type can be switched from "f" to "symlink" and back, and
add code to the dos_open() routine so that ESYMLINK is returned if an open
is attempted on a symlink and ACC_SYMLINK isn't set in the modes bitmask.

When the path lookup loop in libc/open.c gets ESYMLINK, it opens the file
with ACC_SYMLINK, gets the contents, replaces the current path element with
this contents, closes the symlink file, and continues.

Thus my work on shared libraries. An important change like this requires
each and every a.out to be rebuilt to get the new C library code. I've
known shared libraries are needed for a LONG time, but this was the event
which kicked me into action.

Now, administrivia. It looks like the list is picking up steam. Remember
that we have a digest format available; send mail to vsta-request@cisco.com.
Also, we have a shared library list (vsta-shlib@cisco.com); also send
a request to vsta-request@cisco.com to join it. Let's keep shlib discussion
on that list; if I write up a decent summary of how VSTa shared libraries
work, I'll still send it to the main list. If somebody comes up with an
eloquent summary of why my design proves I'm crazed out of my mind, I guess
that's OK to post to the main list as well. :-)

                                                Andy
Received on Tue Sep 20 09:32:00 1994