GNV dependency avoidable for things traversing VFS from top?

[BenAArmstrong]

Is it possible to avoid a dependency on GNV for a piece of software that needs to traverse the VFS from the root (/) down, filepath component by filepath component? Here's the background to this problem:

Globbing incorrectly uppercased files

JRuby on Rails likes to do a lot of directory globbing, and then filters the results with case-sensitive pattern matches. The upshot of this is that if you have filepaths that were packed up with BACKUP/INTERCHANGE to ship to everyone (where the lowest common denominator for our sites is those still on ODS-2), Rails could not find any '*.rb' files because the globbing returned them as '*.RB' which did not match.

Easy solution here, right? Just use /NOCONVERT and you're fine (or don't use /INTERCHANGE). And you'd think our problems would be over ...

Handling files that are still incorrectly cased

But no, we wanted to also handle cases where we couldn't easily control which way a filepath was cased, so we monkey-patched our Dir.glob calls to automatically use Dir.glob(filepath,File::FNM_CASEFOLD). That at least ensures that if you do, say, Dir.glob('*.dat') all files will be matched even if some of them were uppercased.

This works perfectly for relative paths, but surprisingly, utterly fails for absolute paths. It turns out that JRuby starts at / and directory by directory, finds all matching paths and traverses them. And thinking about this for a minute, that would be important to do on a case-sensitive filesystem that allows multiple filepaths of the same name differing only in case. Well, on our test system, a glob for '/*' was returning nothing!

GNV to the rescue (?)

We noted that our development system did not have this problem whereas the new test system where we were deploying JRuby did. What it came down to is that the development system had GNV installed and the test system did not. Installing GNV fixed the issue.

Now, that just seems like a lot of overhead (pulling in all of that software, where all we really needed was for the root of the VFS to function properly) to make this work. So is there some way to dispense with GNV and set up the POSIX$ROOT just like GNV does?

It's not that I'm terribly opposed to GNV itself. Down the road, we may even find there are more benefits to having it installed. It's just that each new thing we deploy means one more thing to worry about, and at this time, we want to keep things as simple as possible, as we have enough other issues to deal with without having to also worry about what could go wrong with GNV. Suggestions as to how we can best solve this would be appreciated.

Thanks,
Ben

[x2084]

>>>So is there some way to dispense with GNV and set up the POSIX$ROOT just like GNV does?

<<<

Did you try to define the logical SYS$POSIX_ROOT (as a concealed device)? This should do. You can compare your definition with the one GNV makes. It usually is defined as gnu:[000000] where gnu is a concealed device.

You may also read the online help on this, aka $ help crtl feature_logical_names decc$disable_posix_root (it should be easy to understand, at least for a native English reader :-)

[BenAArmstrong]

Ah. I guess I found this bit confusing:

"SYS$POSIX_ROOT" [super] = "_DSA2:[1798,122,256.]" (LNM$SYSTEM_TABLE)

This is just optimization I suppose? I see it does indeed just point at GNU:[000000].

The help was very illuminating. Thanks. Dunno how I missed that!

Ben

[Martin Vorlaender]

Concerning the (invalid) FID in the directory spec, see Fun with GNV at HoffmanLabs

cu,

  Martin

[x2084]

The DID abbreviation in PSX$ROOT  is set by $ SET ROOT, which sets the system root and creates the logical name.  (The name  is confusing, it has the same  facility name prefix as the obsolete VIP product.) The system root is used for posix path names in RMS. That is for the file specs with prefix ^UP^. The logical name just visualizes where the root is. You can deassign it any time, RMS will still find posix path names. (A more descriptive logical name would have been sys$posix_root or rms$posix_root.)

In GNV$STARTUP.COM, GNV checks, whether there is a root set up with SET ROOT. If it is, it uses it and defines a SYS$POSIX_ROOT with the same equivalence string. (The name is confusing, because is is not the system root, it is the root used by the CRTL (hence by GNV) and a name like decc$posix_root would have made that more obvious.)

There is/was a problem with setting up the correct DID for the system root. So the wrong DID ended up in the CRTL root as well. However, I do not know whether the problem only shows/-ed in the logical names or also in RMS when specifying the ^UP^/.

PS: The FID abbreviation needs the ~ prefix. For a directory file with fid (47,11,0) $ dir ~[47,11,0] shows the directory file and $ dir [47,11,0] lists the files in the directory.