[Info-vax] Base/root directory for users on single disk VAX

[Stephen Hoffman]

On 2019-01-20 16:08:06 +0000, abrsvc said:

Short Answer:

Sure, use a concealed rooted logical name here.  It'll work fine.   But 
do expect the possibility of an oddity or two, particularly if there's 
code around that tries to parse the resulting OpenVMS path 
specifications.



Long Answer:

> The rooted directory suggested is built in the same manner as SYS0 (for 
> example).

Ayup.  That particular example is a concealed, rooted, searchlist 
logical name, and which adds extra "fun" to the path parsing.

I've met add-on code that failed when it was placed in 
SYS$SYSROOT:[SYSEXE] or SYS$SYSROOT:[SYSMGR].   DCL and otherwise.

> Why would there be any problem with using the technique?

The technique proposed works fine.  The "fun" is in other and unrelated 
DCL that then tries to parse the resulting path specifications.  
Various of that code fails.

Various of the parsing code I've worked on and some of what I've 
written doesn't (or didn't) deal with concealed, rooted logical names.

More than a little DCL code also can't deal with the use of $ in the 
allocation class or in the SCS host, or ^ escape, or UP^, or ' in 
names, or , in directory names, or the dot version, or zero or negative 
versions, or <>, or otherwise.  Or deep directories or ~4K-length 
filenames.  Or the use of FID'd and DID'd paths.  Or of UTF-8 names, 
because you can't count bytes and characters as the same with UTF-8.  
There are all sorts of corner cases here.   Or the proposed increase in 
file version from ;32767 that VSI floated a while back.

Various long-time OpenVMS app developers haven't really gotten to 
ODS-5, and follow what they consider a safe subset.  If they even 
realize that what they're working with is a subset.

Most of the time, these latent (broken) assumptions and these coding 
errors will simply cause the app to tip over.  But I'd expect a few 
cases might lurk where these could well be used for filter evasion or 
other nefarious purposes, too.

There's a whole lot of app code around that can't deal with the current 
range of OpenVMS filename and path syntax and that just based on 
potential ODS-5 filename length, and there's a whole lot that can't 
parse provided paths.

> Also, I doubt that any user in the case specified would be using PCSI 
> utility for anything.

That was a comment intended to point out that the OpenVMS development 
folks themselves can't get filename parsing right.   This stuff is not 
easy, and it's getting less-easy.  There's still no API for parsing and 
constructing and deconstructing file paths and logical names from 
within DCL and that some forty years on—f$parse is weak for what 
various folks need—and the RMS path-parsing APIs aren't that much 
better.  And basename() doesn't know from OpenVMS path syntax.




-- 
Pure Personal Opinion | HoffmanLabs LLC