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 :-{
Peter,
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 . . .
____________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
