1748223 Members
4681 Online
108759 Solutions
New Discussion юеВ

RMS v. symbolic links

 
Steven Schweda
Honored Contributor

RMS v. symbolic links

"on a COMPAQ Professional Workstation XP1000
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.)
10 REPLIES 10
Hoff
Honored Contributor

Re: RMS v. symbolic links

AFAIK, the standard OpenVMS APIs are supposed to be able to open a file via its symbolic link.

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.)


Steven Schweda
Honored Contributor

Re: RMS v. symbolic links

> AFAIK, the standard OpenVMS APIs are
> 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.
Hoff
Honored Contributor

Re: RMS v. symbolic links

Can you forward over the zip or unzip C code involved here, and I'll take a look at it?


Steven Schweda
Honored Contributor

Re: RMS v. symbolic links

My semi-reduced (untidy) test case should be
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.
Hoff
Honored Contributor

Re: RMS v. symbolic links

first comment: Where's FAB$M_NAM set?
Steven Schweda
Honored Contributor

Re: RMS v. symbolic links

> Where's FAB$M_NAM set?

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)?
Steven Schweda
Honored Contributor

Re: RMS v. symbolic links

Setting fab.fab$v_nam = 1 seems to have no
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.
Steven Schweda
Honored Contributor

Re: RMS v. symbolic links

For another instance of symlinks causing
"%RMS-F-ORG, invalid file organization
value" (in BACKUP), see:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1104948
Guy Peleg
Respected Contributor

Re: RMS v. symbolic links

To instruct RMS NOT to follow a symbolic
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