At 9:27 PM -0500 3/21/00, Carl Friedberg wrote:
>I was not proposing a swap of vms$common for syscommon, but rather a test in
>configure or subconfigure, warning that the system disk was misconfigured. I
>don't think it would be wise to try to work around a problem like this; the
>user should get her sysadmin to fix this up.
I don't think the system disk is misconfigured, is it? It's just that SYSCOMMON.DIR
pretends it's a top-level directory in order to make all the cluster stuff work.
>Likewise, if a user choses, as Peter has done, to use a logical name in the
>mount command
[snip]
>which then conflicts with a logical name which he defines at some later time
[snip]
>there really is nothing perl can, or should do, to "fix" this; a warning
>should be issued (if we can figure this out --- not sure we can); but it
>really is not something we can work around.
I'd agree except that in Perl_cando() we already know the physical device name and the
fid; if we can't get at the file armed with those two things, then we really are in
trouble.
>From my own testing, it is clear
>that the problem is that the exec mode logical name which is created when
>the device is mounted in this manner (with the third argument specifying a
>logical name) is what is returned by dvi_logvolnam; and when you replace it
>by defining (with system privs)
>an identical logical name in the same mode:
>
>$ define/system/exec user $1$dka1:[u.] /trans=conc
>
>then -- I was going to say, it would return the new value, but no:
> ooops, I've been going along checking this on a 7.2-1 Alpha, and once I do
>this define, f$getdvi ("DKA1:","LOGVOLNAM") returns ""... so now I am
>totally confused.
Do you really have a DKA1: on your system? Further down you are testing with DKA100:.
If you do, then this suggests there is now some smart code in the DEFINE command to
prevent the sort of problem we are discussing. I'd be really curious to see what
lib$fid_to_name returns; do you have my fidvoltest program?
Thanks for the input.
____________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
