- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- GNV dependency avoidable for things traversing VFS...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-30-2011 07:39 AM
тАО06-30-2011 07:39 AM
GNV dependency avoidable for things traversing VFS from top?
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-30-2011 09:53 AM
тАО06-30-2011 09:53 AM
Re: GNV dependency avoidable for things traversing VFS from top?
>>>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 :-)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-30-2011 11:00 AM
тАО06-30-2011 11:00 AM
Re: GNV dependency avoidable for things traversing VFS from top?
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-01-2011 03:30 AM
тАО07-01-2011 03:30 AM
Re: GNV dependency avoidable for things traversing VFS from top?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-01-2011 06:26 AM
тАО07-01-2011 06:26 AM
Re: GNV dependency avoidable for things traversing VFS from top?
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.