Craig A. Berry wrote in repsonse to me:
> At 7:19 PM -0800 3/14/2000, [EMAIL PROTECTED] wrote:
> >
> >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...
> Note that lib$fid_to_name is being passed a device name that it got
> from a stat structure that was passed to Perl_cando, so I think it's
> just a bit further upstream. We could have a cache bug in Perl or
> the C RTL, although it's odd you are the only one getting this. My
> current guess would point the finger at the following fix in
> alpacrt09_071, details at
> <http://ftp1.support.compaq.com/public/vms/axp/v7.1/alpacrt09_071.CVRLET_TXT>.
> I don't have this patch installed, which might be why I
> don't see the problem even though I'm at 7.1 also.
>
> Quote from the patch cover letter:
>
> 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).
> end of quote
>
> Are we depending on a feature that has now been declared a bug? Or
> did correctint a bug in stat() introduce a new one? Or are we even
> using the C RTL's stat?
>
> What happens if you say
>
> $ mcr dkb100:[vmsperl]miniperl . . .
>
> instead of
>
> $ mcr sys$disk:[]miniperl . . .
OK I don't think that change to stat() was relevant. The problem dawned
on me last night: The Volume label for my dkb100: device is DISK$USER: or
simply USER: if you omit the DISK$ part (which is what the return from
lib$fid_to_name() was giving) hence you wind up with
USER:[VMSPERL.VMS]WRITEMAIN.PL. I happen to have a logical name defined
like so:
$ DEFINE /SYSTEM /TRANSLATION_ATTRIBUTES=(CONCEAL,TERMINAL) USER DKB100:[u.]
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].
The documentation for lib$fid_to_name mentions the following:
LIB$FID_TO_NAME uses the directory backpointer stored in the file header.
With files in SYS$COMMON, the directory structure is duplicated because of
some SET FILE/ENTERs of directory names. If directory names have been
renamed or the tree structure modified (which the OpenVMS operating system
does with the [SYCOMMON] tree), the file specification returned by this
routine may not be useful.
Hence the problem I am seeing is a bug in vmsperl for using lib$fid_to_name().
Craig I believe that you could reproduce my trouble building vmsperl, if as
your post from yesterday indicated you had a build tree in
DISK8:[BERRYC.VMSPERL...] then assuming that DISK8 is DKA800: (or some such -
please do s/DKA800/$your_physical_device/ in what follows) try doing this:
Create an empty directory:
$ create /dire DKA800:[NONESUCH]
Define a DISK8 logical name to point into the new empty directory:
$ DEFINE /SYSTEM /TRANSLATION_ATTRIBUTES=(CONCEAL,TERMINAL) DISK8 DKA800:[NONESUCH.]
Go back to your build directory, move the good build aside (if you prefer)
and re-extract the tarball:
$ set def DKA800:[BERRYC]
$ rename VMSPERL.DIR VMSPERL_GOOD.DIR
$ tar/extract/verb/date=none VMSPERL_RC1_1.TAR
$ set def [.VMSPERL]
$ @configure "des"
Your build should then fail to find writemain.pl if I am correct about what is
going wrong here.
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.
