- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- RMS v. symbolic links
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
тАО02-28-2007 04:51 PM
тАО02-28-2007 04:51 PM
RMS v. symbolic links
running OpenVMS V8.3"
Should I be able to open a symbolic link (_not_
the file to which it points) using sys$open()?
If I do things the easy way, setting up the FAB
and NAML blocks as usual, then sys$open() will
follow the link. If I set the magic NAML bit,
naml$v_open_special, then sys$open() fails,
with status %x0001860c = "%RMS-F-ORG, invalid
file organization value".
Is there some clever trick which would allow
this to work, or am I doomed with RMS? (I can
get the desired result at a level lower than
RMS, but I have a chunk of code which collects
file attributes, and I'd _really_ prefer not to
re-write the whole thing to use sys$qio() and
its friends.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-01-2007 05:01 AM
тАО03-01-2007 05:01 AM
Re: RMS v. symbolic links
Or are you attempting to look directly at the contents of the symbolic link, and are not seeking to "dereference" it.
Did you happen to set naml$v_open_special in the NAML field by accident, and not the intended naml$m_open_special? (Bit vector v. bit mask.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-01-2007 05:25 AM
тАО03-01-2007 05:25 AM
Re: RMS v. symbolic links
> supposed to be able to open a file via its
> symbolic link.
That does seem to be true. However, I'm
trying to deal with the link itself. As I
said, "_not_ the file to which it points".
(Which is why I'm setting the magic NAML
bit.)
I'm not even trying to see its contents, just
hoping to use sys$display() to populate some
XABs, as has been done with normal files for
some eons now. (Think "zip -V", the
old-fashioned way.) But, as the
documentation says:
A file must be open for access by a Create
or Open service before the Display service
can be invoked.
> (Bit vector v. bit mask.)
[...]
static struct NAML nam;
[...]
nam.naml$v_open_special = 1;
[...]
I believe that I'm setting the bit properly,
I just expected more cooperation from
sys$open() when I set the thing.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-01-2007 05:40 AM
тАО03-01-2007 05:40 AM
Re: RMS v. symbolic links
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-01-2007 06:30 AM
тАО03-01-2007 06:30 AM
Re: RMS v. symbolic links
available at:
ftp://antinode.org/misc/rt.c
http://antinode.org/ftp/misc/rt.c
It runs as expected when given a normal file,
but fails on a symlink. There's also an
"ft.c" which uses sys$parse() and
sys$search() to test the magic NAML bit.
The actual Zip code is in [.vms]vms_im.c in
any recent source kit. The change I was
hoping to make was something like this in
front of the first sys$open() (at least):
#ifdef NAML$M_OPEN_SPECIAL
if (linkput)
{
nam->naml$v_open_special = 1;
}
#endif /* def NAML$M_OPEN_SPECIAL */
Nowadays, the default is to use vms_pk.c
instead of vms_im.c, and I seem to have that
one working, but I was hoping to be able to
keep the old IM scheme in step, in case
anyone still cares.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-01-2007 07:43 AM
тАО03-01-2007 07:43 AM
Re: RMS v. symbolic links
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-01-2007 08:07 AM
тАО03-01-2007 08:07 AM
Re: RMS v. symbolic links
You got me. Nowhere? I don't see where
anyone ever sets it in any of this stuff.
A quick look through SYS$EXAMPLES turned up
only one instance of anyone setting
FAB$M_NAM. Everyone else just points
fab$l_nam to the NAM block, and all's well.
No one seemed to need it before I set
naml$v_open_special. Are you saying that
all this stuff is really broken (but lucky)?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-01-2007 09:31 AM
тАО03-01-2007 09:31 AM
Re: RMS v. symbolic links
effect.
Exactly who uses what why (and when) in
these structures has always been a bit of a
mystery to me. The RMS manual is wordy on
FAB$V_NAM, but the comment in FABDEF.H seemed
clearer:
/* use name block dvi, did, and/or fid
fields for open */
I don't actually care about these XXX fields,
as I was assuming that the underlying
services would start with the file spec (in
the FAB or NAML) and fill in whatever they
needed (wherever they needed it). Which
seems to be true.
In the RMS case, sys$open() seems to be
happy enough when it follows the symlink to a
plain file, but when naml$v_open_special
stops it at the symlink itself, it gets all
haughty and uncooperative.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-01-2007 05:05 PM
тАО03-01-2007 05:05 PM
Re: RMS v. symbolic links
"%RMS-F-ORG, invalid file organization
value" (in BACKUP), see:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1104948
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-04-2007 08:47 AM
тАО03-04-2007 08:47 AM
Re: RMS v. symbolic links
link all that is required is to set
NAML$V_OPEN_SPECIAL in NAML$L_INPUT_FLAGS.
If this does not work, I suspect you might
have a coding error somewhere.
As a start test lexical function
F$SYMLINK_ATTRIBUTES and see if it works.
F$SYMLINK is identical to F$FILE (same item code, same options) but will operate on the symbolic link instead of following it. If this works, it will provide a proof that
your environment is set up correctly.
Then look at the code and verify you are
setting NAML$L_LONG_RESULT and NAML$L_LONG_EXPAND.
If it still does not work, please post a small example.
Guy Peleg
BRUDEN-OSSG
http://www.brudenossg.com