At 7:24 AM -0500 3/16/00, lane @ DUPHY4.Physics.Drexel.Edu wrote:
> > At 4:44 PM -0800 3/15/2000, [EMAIL PROTECTED] wrote:
> > 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)

Although the trail of speculation included many guesses about
compiler and OS bugs, I think where we are now is that
lib$fid_to_name sticks in the volume label for the device part of a
filespec, presumably in any version of VMS (although that remains
untested).  This behavior works fine unless the volume label is
identical to a rooted logical that points to somewhere other than the
root of the same device.

>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.

Right.  I don't see any evidence that directory backlinks are the
problem, but I took Peter's point to be that they definitely *would*
be a problem if someone were executing a Perl_cando() on a file in
SYS$COMMON, and that may indeed be true given the way we are
currently using lib$fid_to_name.  On the other hand, if it gives you
*a* valid name for the file, that may be all you need even if it's
not the *only* valid name.

>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.

Hmm.  I assume it's doing a chain of $QIOs back up the directory tree
until it gets to the root directory, sort of the opposite of what
sys$open does.  The docs aren't clear on exactly what the ACP status
is.  Is it just the status from the iosb of the most recent $QIO?
The I/O User's Guide might have something on this, but I'm not sure
it would help us unless it tells us about ambiguous backlinks, which
again wouldn't help us with the volume label/rooted logical conflict.

The trouble comes when it fills in the device name (or really the
volume label).  I'm not sure why it uses the volume label other than
it perhaps figures you already have the big ugly full device spec
because you passed that on input.  Hopefully I'll find some time to
put together a little dummy program and nail down exactly what's
happening and what to do about it.

____________________________________________
Craig A. Berry                   
mailto:[EMAIL PROTECTED]

Reply via email to