At 02:23 PM 3/21/00 -0500, Dan Sugalski wrote:
>At 01:15 PM 3/21/00 -0600, Craig A. Berry wrote:
>> This file hunting code should work (and in fact does so long as the volume
>>logical is not redefined) but it apparently never gets hit unless
>>ALWAYS_DEFTYPES is enabled.
>I bet this'd bite with older versions of perl and the -S switch. There's no reason
>not to have some defensive code in there to catch it, though.
Other than such code being difficult to write, difficult to test, and
causing a potentially annoying performance hit :-(. Not that such things
have stopped us before :-).
For starters, we could flag problems at build time by putting something like
this in configure.com:
$ testspec = f$getdvi("sys$disk", "logvolnam") + ":" + f$directory() + "manifest."
$ if f$search(testspec) .eqs. "" then write sys$output "Do you know what FUBAR stands
for?"
Peter, if you try that in your Perl build directory, it should, if I'm
right, ask you a question you know the answer to all too well.
Trying to make Perl_cando() smart enough to mistrust the device name it gets
back from lib$fid_to_name could be a bit trickier. It looks like it's
absolutely necessary in some cases, though. As Peter suspected, if you give
lib$fid_to_name something in SYS$COMMON, it won't give you back something
useable:
$ r fidvoltest
Enter a complete path to a known file: sys$common:[sysexe]loginout.exe
stat() says sys$common:[sysexe]loginout.exe is file 488, 2, 0 on device _BUBBA$DRA0
lib$fid_to_name gives a resulting name of DISK$DISK13:[SYSCOMMON.SYSEXE]LOGINOUT.EXE;1
but what lib$fid_to_name returns is of course not there because the SYSn
part of the dirspec is missing:
$ dir DISK$DISK13:[SYSCOMMON.SYSEXE]LOGINOUT.EXE;1
%DIRECT-E-OPENIN, error opening DISK$DISK13:[SYSCOMMON.SYSEXE]LOGINOUT.EXE;1 as input
-RMS-E-DNF, directory not found
-SYSTEM-W-NOSUCHFILE, no such file
when what's really there is:
$ dir DISK$DISK13:[SYS0.SYSCOMMON.SYSEXE]LOGINOUT.EXE;1
Directory DISK$DISK13:[SYS0.SYSCOMMON.SYSEXE]
LOGINOUT.EXE;1
Total of 1 file.
I suppose this is a result of the backlink problem we discussed earlier,
i.e., SYSCOMMON.DIR refuses to acknowledge its parentage in SYSn, where n
depends on what node in the cluster you're on. In any case, if we start
thrashing around in here to solve redirected volume logicals, we should also
try to figure out what to do with missing backlinks. Ugh.
_______________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
