"Craig A. Berry" <[EMAIL PROTECTED]> writes:
> At 4:44 PM -0800 3/15/2000, [EMAIL PROTECTED] wrote:
>
>>This is almost but not quite accurate. The call to stat() upstream of
>>Perl_cando results in a device name of _SNFRN$DKB100:, whereas the call to
>>lib$fid_to_name() returns USER:[VMSPERL.VMS]WRITEMAIN.PL, this happens
>>to be a problem because I have a USER rooted logical. I did not say that
>>lib$fid_to_name() was turning DISK$USER: to USER:, I did say that it was
>>turning _SNFRN$DKB100: to USER: and that we ought not use it.
... more details snipped....
(I don't see this problem [vms6.2], so my comments are general)
>>$ sho log user
>> "USER" = "DKB100:[U.]" (LNM$SYSTEM_TABLE)
>>
>>So strictly speaking lib$fid_to_name() is not wrong, it is behaving as
>>documented and it is documented to be capable of returning file specifications
>>that "may not be useful". We ought not be using it (at least with DECC 6.0).
Well, the manual says it "may not be useful" if you're using files or
directories that have SET FILE/ENTER stuff to modify directory backlinks.
Is that the case on your DKB100 disk?
One thing that might be worth trying is to grab the ACPstatus returned
by lib$fid_to_name ... it *sounds* from the docs like it's getting
its info from RMS, and that's where the problem may be originating.
One should be able to extract a snippet of code (just a stat() and
lib$fid_to_name) that can duplicate the problem without having to test
it inside of Perl. Then it can be added to SUBCONFIGURE so that a
compile flag can be set appropriately :)
--
Drexel University \V --Chuck Lane
----------------->--------*------------<[EMAIL PROTECTED]
(215) 895-1545 / \ Particle Physics [EMAIL PROTECTED]
FAX: (215) 895-5934 /~~~~~~~~~~~ [EMAIL PROTECTED]
