At 06:01 PM 3/21/00 -0500, Dan Sugalski wrote:
>Well, if we get a device back (say USER) then we go look for a logical. If that
>logical exists then we translate the device name to a physical name and use that,
>otherwise we use the device name. That should work, unless I'm confused, which has
>happened before. :)
I don't know if you are confused or not, but I don't think translating the
logical is what we want. At the risk of confusing everyone, including
myself, more, let me try to explain again. lib$fid_to_name will always
return a logical name as the device part of the file spec. To be specific,
it will return DVI$_LOGVOLNAM, which is created by the MOUNT command. The
logical name is squirrelled away somewhere (perhaps VOLSET.SYS or the home
block of INDEXF.SYS) as well as being placed in the system logical name
table at the time the disk is mounted.
The problem arises when the logical has been redefined after the MOUNT such
that there is a discrepancy between what the file system has recorded in its
innards and what the logical name table holds. The former may
assume, for example, that USER translates to DKB100:, but the latter may
say that USER actually translates to DKB100:[USER.]. This is what happened
in Peter's case, and we could catch this by translating USER and checking
for stuff after the colon; the MOUNT command should never create a logical
that has a directory part in its translation.
But what if the redefinition of the volume logical was to another disk, not
to another directory? Or what if the logical has been deassigned entirely
and doesn't exist? Perhaps we can avoid the whole mess by just using the
physical device name returned by stat() (and fed to lib$fid_to_name on
input). In this approach there would be no translation of the returned
device spec, just straight substitution. I suggested several messages back
that this wouldn't work, but I now suspect it might in all cases except the
SYSCOMMON-type backlink examples, which need another solution anyway.
>> >I'd like to have some way to fix the problem for SYS$COMMON and suchlike linked
>directories, though I don't know how at the moment. :(
>>
>>Following Carl's suggestion, perhaps it's as simple as a substitution on the file
>spec:
>>
>>s/[SYSCOMMON/[VMS$COMMON/
>
>Yeah, but if there are other linked directories we'd still lose. Of course, the docs
>*strongly* discourage this, but I'd hate to get bit by it.
I agree a more general solution would be nice. If the problem, though, is
that a subdirectory doesn't know who its true parent is, then I don't see
any way around it other than supplying that information from some external
source. I wonder what happens if we do a sys$open by fid and then look in
the NAM block?
_______________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
