[14096] in Athena Bugs
sun4 7.7U: attach
daemon@ATHENA.MIT.EDU (Abbe J Cohen)
Fri Jan 5 00:47:13 1996
To: bugs@MIT.EDU
Date: Fri, 05 Jan 1996 00:47:07 EST
From: Abbe J Cohen <abbe@MIT.EDU>
System name: m37-332-3
Type and version: SPARC/5 7.7U
Display type: cgthree
What were you trying to do?
I attached a locker (/mit/assassin) that was on procrustes.
It was already attached from a previous user, and told me the
usual message about filesystem already attached; authenticating.
I expected it to behave normally after that, ie, be attached,
let me access it, authenticate me, ** tell me via filsrv if
anything was happening to it, etc. **
What's wrong:
I'm lazy; I didn't bother to check whether anything I use is on
the zillions of fileservers that are being updated to 7.7 over
the next/past few days. Procrustes went down to be updated to 7.7;
** I never got notified by a filsrv message beforehand.
What should have happened:
I should have received a filsrv message about procrustes going
down before getting an afs:lost constact with procrustes message.
** Attach should have subbed me to this filsrv message.
Please describe any relevant documentation references:
There are two places that could potentially subscribe me to the correct
filsrv messages: zinit, for lockers already attached by me when start
zwgc, and attach, for lockers that I attach while I'm logged in.
what man attach has to say about it:
....
-zephyr or -z
Subscribe to Zephyr messages about the server host.
** This is the default. **
....
When an attach is successful and the -nozephyr option is not
specified, a Zephyr(1) subscription is made for the user for
filesystem status message for the appropriate server. These
subscriptions are removed when the filesystem is detached.
what man zinit has to say about it:
Zinit subscribes to class FILSRV, instances servername and
servername:filesystem or servername:pathname for remote NFS
and RVD filesystems found in attachtab, where servername is
the name of the machine providing the file service. For
type AFS filesystems, instances afs:cell:volume and afs:cell
are subscribed to, where cell and volume are the cell and
volume names of the root of the filesystem. In addition, if
the root of an AFS filesystem is not replicated on multiple
servers, instance afs:servername is subscribed to.
** By default, only messages about filesystems attached by the
user running attach or root are subscribed to. The -a
option selects all remote filesystems, while -m selects only
those attached by the user. -q, -d, and -v have the same
meaning as in attach(1).
It's definitely not getting done by zinit, this seems reasonable and
fits with the documentation. It's also not getting done by attach,
although I'm not sure whether this matches the man page or not: I'm
not sure what defines a "successful" attach. Either me typing "attach
lockername" for a locker that is already attached on that workstation
is "unsuccessful" (even though I don't think anything has gone wrong,
since the locker is now attached and I can use it), and the man page
is right; or that case is "successful" and the man page is wrong or
the behavior doesn't match it or whatever, since I'm not getting
subbed to the zephyrs.
Either way, what I _think_ should happen is that whether or not a
locker is already attached when you try to attach it, you should be
subbed to the filsrv zephyrs for the server it's on, since you typing
attach implies you intend to use the locker and want to know what's
going on with it. Sorry if this is long, I was filling up the time
waiting for procrustes to come back up so I could finish what I was
doing. =}
-abbe
