Hi Peter
I have a feeling that USER is one of those logical names that get's us in
trouble.
We've had a system level concealed logical name of USER since day one, as
the system derives from (as in it's the same system management environment)
MicroVMS 4.x. USER is defined that way on MicroVMS, or at least that was one
of the default definitions that came with the box. I think I've whined about
this once in the past; perl on VMS should be aware of this as a possibly
"standard" vms logical name.
Oh, I think I hit a problem in one of Dan's extensions, but that's not
relevant here.
So, you are saying that because you do a
$ mount /system $1$DKB100: USER
you get the systme logical disk$user (translates to _$1$DKB100:), and that
you have the concealed logical
$ DEFINE /SYSTEM /TRANSLATION_ATTRIBUTES=(CONCEAL,TERMINAL) USER
DKB100:[u.]
somehow lib$fid_to_name is confusing disk$user with the concealed logical
user? That's a VMS bug...
[EMAIL PROTECTED]
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> >Thus lib$fid_to_name() apparently feels compelled to change a perfectly
OK
> >device name doing s/\Q_SNFRN$DKB100\E/USER/ for some odd reason. The bug
is
> >Compaq's and I now have to hunt up a patch :-{
OK I now have to retract that assertion. There is not necessarily a bug in
lib$fid_to_name(). See below...
> o The stat() function has been corrected to process file
> specifications such as "foo:[000000]", where foo is defined as
> a concealed device like the following:
>
> $ define/trans=(conc) foo device:[bar.]
>
> Prior to this fix, the stat() function would fail for such a
> file specification with errno set to ENOENT (No such file or
> directory).
And while there is a DISK$USER:[VMSPERL.VMS]WRITEMAIN.PL;1 there is no
USER:[VMSPERL.VMS]WRITEMAIN.PL;1 since there is no VMSPERL.DIR in
DKB100:[U].
...
Perhaps Perl_cando() ought to trust the return from stat() rather than
making use of the apparently untrustworthy lib$fid_to_name(). This bug
will bite folks who use perl to mess about with SYS$COMMON among other
things.
Peter Prymmer
P.S. The y2k patches to vms (which were installed on the machine in
question)
included a fix to lib$fid_to_name() that merely did the following:
o LIB$FID_TO_NAME has been modified to ensure that the use of
very deep directory trees do not result in the call stack being
corrupted.
but that is still not relevant to the problem of vms.c using
LIB$FID_TO_NAME.
