Craig wrote: >> 2.) Another thing that I think will be surprising about vms_realname >> and vms_realpath is that they translate concealed logical names.
Maybe it helps to understand what LIB$FID_TO_NAME does. It takes just two arguments right? device + file-id The path to a file typically drills down from a logical name to a device + directory and down into sub directories and ultimately the directory has an entry for a name returning the file-id. But the same file id might have multiple entries, in multiple directories. Typically it's just one entry in one directory, but that's no requirement. (SET FILE/ENTER) The (concealed) logical name is a different story. That could easily be just something existing in the context of a single process, and even for just a little time. And both 'd0' and 'd1' could easily be concealed paths to the same directory, For example if the default devices for some users which used to be split over separate physical devices have been consolidated onto a single device, and even a single (top) directory. now back to LIB$FID_TO_NAME it takes the FID to read the corresponding FILE HEADER from INDEXF.SYS for the device specified. The file header has a name ($DUMP/HEAD/BLOCK=COUNT=0), which will be returned and which may or might not correspond with the name you use to find the file. It also has 1, and only 1, directory backlink (FID) which you may or might not have used to address the file. It walks the backlinks up to [000000] (FID=4,4,0) and then declares victory. There is no room for (concealed) logical name usage anywhere in that path back! Hope this helps someone some day, Regards, Hein.
