Any known problems with SYMLINKS ?

[P Muralidhar Kini]

Hi All,

I have created this thread so that people can report various problems that they are aware, related to usage of V84 SYMLINK. I will make a note of these problems and log a internal problem report for each one of them.

This discussion initially started in the following thread -
http://h30499.www3.hp.com/t5/Languages-and-Scripting/GNV-behavior-and-the-DECC-incantations/m-p/4754824#M8072
I have now created this new thread to continue the discussion.

Regards,
Murali

[P Muralidhar Kini]

INFORMATION PROVIDED BY : *** H.Becker ***

>>> The SYMLINK feature was added in OpenVMS V83 version.
<<<
The SYMLINK feature was added in OpenVMS V7.2-6C2. However, there was no DCL interface. It was redesigned for V8.3, now with DCL support. It was rewritten to fix bugs and improve performance for V8.4. Unfortunately all the changes are incompatible: you can't use previous symbolic links in current versions. With all the changes and bug fixes it is recommended to avoid symlinks on older versions than V8.4.

>>> On VMS, you can't symlink a directory (well you can, but it doesn't work when you try to query it)
<<<
Symlinks for directories kind of work, but you have to be careful (on an ODS5 disk with Parse Style: Traditional and Case Lookup: Blind):
$ cre/dir [.sub]
$ cre [.sub]foo
[ Exit ]
$ cre/symlink=sub lnsub
$ dir [.lnsub]

Directory USER01:[BECKER_H.SYMLINKS.LNSUB]

FOO.;1

Total of 1 file.
$ create sub.
huhu
Exit
$ type lnsub.
huhu
$

>>> you can't symlink to absolute pathnames that are not on one of those POSIX root GNV mount point thingies
<<<
Not really true on V8.4.
$ def the_sub USER01:[BECKER_H.SYMLINKS.SUB]
$ cre/symlink="/the_sub" there
$ dir /date

Directory USER01:[BECKER_H.SYMLINKS]

LNSUB.;1 -> SUB 21-FEB-2011 20:19:44.93
SUB.;1 21-FEB-2011 20:25:19.02
SUB.DIR;1 21-FEB-2011 20:18:44.42
THERE.;1 -> /the_sub
21-FEB-2011 20:37:38.95

Total of 4 files.
$ dir [.there]

Directory USER01:[BECKER_H.SYMLINKS.THERE]

FOO.;1

Total of 1 file.
$

>>> symlink on a volume that has write behind caching enabled because readlink() won't find it until the cache is flushed.
<<<
And vice versa. It's a bug.
$! same command, error is expected:
$ cre/symlink="/the_sub" there
%CREATE-E-SYMLINKERR, error creating symbolic link THERE
-RMS-E-FEX, file already exists, not superseded
$ del there.;*
$ cre/symlink="/the_sub" there
%CREATE-E-SYMLINKERR, error creating symbolic link THERE
-RMS-E-FEX, file already exists, not superseded
$! unexpected error, what else should I delete?
$! after waiting a while ...
$ cre/symlink="/the_sub" there
$

And yes, symlinks are for GNV:
$ bash
bash$ ls there/
FOO
bash$

[P Muralidhar Kini]

INFORMATION PROVIDED BY : *** Craig A. Berry ***

Murali. Thanks for the offer. Here goes.


Hans wrote:

>Symlinks for directories kind of work

Thanks for the working example. I was working from a C example that I thought I had reproduced using pretty much what you do here in DCL, but I might've fumbled something and I don't have the details handy.

>>> you can't symlink to absolute pathnames that are not on one of those POSIX root GNV mount point thingies
<<<
>Not really true on V8.4.

Good to know. On v8.3-1H1 it's not there yet:

$ create/symlink="/sys$manager/operator.log" op.lnk
$ type/tail op.lnk
%TYPE-W-OPENIN, error opening DISK8:[BERRYC.TEST]op.lnk;1 as input
-RMS-E-DNF, directory not found
-SYSTEM-W-NOSUCHFILE, no such file

>>> symlink on a volume that has write behind caching enabled because readlink() won't find it until the cache is flushed.
<<<
And vice versa. It's a bug.

And here is a reproducer in C. (And it's really unlink(), not readlink() that is unable to deal with cached file headers):

$ type symlink_nowritethru.c
#include
#include
#include
#include

main() {
char fn[]="regularfile.tmp";
char sl[]="symlink.tmp";
char buf[30];
ssize_t buflen;
int saved_errno = 0;
FILE *f;

if ((f = fopen(fn, "w+")) == NULL)
perror("fopen() error");
else {
fprintf(f, "I am not a symlink!");
fclose(f);

if (symlink(fn, sl) != 0)
perror("symlink error");
else {

if ((buflen = readlink(sl, buf, sizeof(buf))) != -1) {
buf[buflen] = '\0';
printf("# readlink() succeeded, '%s' points to '%s'\n",
sl, buf);
}
}
}

/* clean up */
if (unlink(sl) != 0)
perror("Couldn't unlink symlink");
if (unlink(fn) != 0)
perror("Couldn't unlink regular file");

}

Make sure you're on a volume with write-back caching enabled via SET VOLUME/NOWRITETHROUGH and notice that it cannot unlink the symbolic link it's just created:

$ write sys$output f$getdvi("SYS$DISK:", "WRITETHRU_CACHE_ENABLED")
FALSE
$ r symlink_nowritethru
# readlink() succeeded, 'symlink.tmp' points to 'regularfile.tmp'
Couldn't unlink symlink: no such file or directory
$ dir symlink.tmp

Directory DISK8:[BERRYC.TEST]

symlink.tmp;1

Total of 1 file.

Run it on a volume without write-back caching and it removes the symlink just fine.

[Hoff]

Not specifically Symlinks, but items that cause problems and issues with GNV...

The DCL command SET ROOT (used to establish the root directory for GNV) does not (did not) correctly process directory files with non-zero NMX fields within FIDs, so a root that's allocated with a FID above the capacity of the NUM field within the FID (and thus non-zero values in the NMX) craters.

Here are some of the other adventures with GNV:

http://labs.hoffmanlabs.com/node/1481

There are further adventures with GNV posted over in the PORTING_TO_VMS conference at DECUServe site, with telnet or ssh into the server being easier, but http access available via:

http://decuserve.org/anon/htnotes/conf?f1=PORTING_TO_VMS

Also kindly consider relocating the private source code repository presently in use for GNV out into a Sourceforge, Bitbucket or Github source code repository (or into a distributed version control system that HP is running on its own public-facing servers, for that matter), rather than the current scheme with a private source code repository with a public ftp download out at Sourceforge. Where we get git pull it or analogous, and where folks can contribute fixes and updates.

[P Muralidhar Kini]

Craig, Becker,

>> you can't use previous symbolic links in current versions.
VERIFY (i.e. ANAL/DISK) on V84 is enahanced to handle & modify the SYMLINKS
created on OpenVMS versions prior to V84.

SYMLINKS created prior to V84 version had a entry in file header indicating that its a SYMLINK. With V84 version, a SYMLINK would not only have a entry in file header but also a bit set in the directory entry indicating that its a SYMLINK.

For SYMLINKS created prior to V84 version, you can run VERIFY (from V84 node) so that it would get that bit set in its directory entry indicating that its a SYMLINK. Once this is done those SYMLINKS can be used in the V84 systems.

Have you tried using the VERIFY from V84 node for SYMLINKS created on OpenVMS version prior to V84 ?
If yes, then can you provide any particular operation that failed acessing such SYMLINKS ?

Problems -
1)
>> $ cre/dir [.sub]
>> $ cre [.sub]foo
>> [ Exit ]
>> $ cre/symlink=sub lnsub
>> $ dir [.lnsub]
>>
>> Directory USER01:[BECKER_H.SYMLINKS.LNSUB]
>>
>> FOO.;1
>>
>> Total of 1 file.
>> $ create sub.
>> huhu
>> Exit
>> $ type lnsub.
>> huhu
>> $

In this case, you have a file "sub." and a directory "sub.dir". SYMLINK is pointing to the text "sub".
SYMLINK is a file which gets a text associated with it.
The command "$ cre/symlink=sub lnsub" is creating a SYMLINK and associating
a text "sub" with it. It would not matter to a SYMLINK whether the text is a file or
directory or even if it exists. When you access the link, the text associated with
the SYMLINK is intepreted based on the context.
"$ dir [.lnsub]" command would interpret the contents of the symlink as a directory
and as it finds a directory, it uses it.
"$ type lnsub" command would interpret the contents of the symlink as a file and
as it finds file, it uses it.

This looks like a expected behavior. Provide your thoughts.

2)
$ create/symlink="/sys$manager/operator.log" op.lnk
$ type/tail op.lnk
%TYPE-W-OPENIN, error opening DISK8:[BERRYC.TEST]op.lnk;1 as input
-RMS-E-DNF, directory not found
-SYSTEM-W-NOSUCHFILE, no such file

Yes, does not work for me on V83 either. It is however fixed in V84 version.

3)
>> And vice versa. It's a bug.
>> $! same command, error is expected:
>> $ cre/symlink="/the_sub" there
>> %CREATE-E-SYMLINKERR, error creating symbolic link THERE
>> -RMS-E-FEX, file already exists, not superseded
>> $ del there.;*
>> $ cre/symlink="/the_sub" there
>> %CREATE-E-SYMLINKERR, error creating symbolic link THERE
>> -RMS-E-FEX, file already exists, not superseded
>> $! unexpected error, what else should I delete?
>> $! after waiting a while ...
>> $ cre/symlink="/the_sub" there
>> $

Yes, i am able to reproduce this problem. Will log a report.

>> And here is a reproducer in C.
>> (And it's really unlink(), not readlink() that is unable to deal with
>> cached file headers):
I am NOT able to reproduce the problem in V84 system.

$set volume $10$DKA0:/writethrough
$write sys$output f$getdvi("$10$DKA0:", "WRITETHRU_CACHE_ENABLED")
TRUE
$r SYMLINK_NOWRITETHRU
# readlink() succeeded, 'symlink.tmp' points to 'regularfile.tmp'
$
$set volume $10$DKA0:/nowritethrough
$write sys$output f$getdvi("$10$DKA0:", "WRITETHRU_CACHE_ENABLED")
FALSE
$r SYMLINK_NOWRITETHRU
# readlink() succeeded, 'symlink.tmp' points to 'regularfile.tmp'
$
Is there any problems with the steps that i have followed?

Hoff,
I will read through the link that you have provided.

Regards,
Murali

[Robert Gezelter]

Murali,

I do not have the time to set up the experiments, but if running ANALYZE/DISK_STRUCTURE is needed to set SYMLINK related bits for correct behavior in 8.4. then:

- What is the behavior of earlier versions with the 8.4 required bits set?

- The note to run ANALYZE/DISK_STRUCTURE should be a BOLDFACE part of the release notes, and quite possibly some other precautions to prevent unexpected problems from arising in the period immediately following an upgrade.

In particular, what about rolling upgrades and transitions?

- Bob Gezelter, http://www.rlgsc.com

[Steven Schweda]

Does BACKUP /COMPARE work yet? On my V8.3
Alpha system, I tend to get stuff like:

%BACKUP-E-OPENIN, error opening ALP$DKA0:[UTILITY.SOURCE.OPENSSL.openssl-1_0_0d.test]md5test.c;1 as input
-RMS-F-ORG, invalid file organization value

[Craig A Berry]

<<<
>> And here is a reproducer in C.
>> (And it's really unlink(), not readlink() that is unable to deal with
>> cached file headers):
I am NOT able to reproduce the problem in V84 system.
>>>

Hmm. What about on v8.3? I don't have v8.4 handy at the moment. It's possible it's been fixed, though it's also possible you have to unmount and remount the volume after setting /NOWRITETHROUGH.

[Craig A Berry]

Bob,

The relevant release notes are at:

http://h30266.www3.hp.com/odl/i64os/opsys/vmsos84/6677/6677pro_gen.html#symlinks_imp

[Robert Gezelter]

Craig,

Thank you for the citation, I did not have the time when I posted that comment to dig through things for the citation.

However, the citation verifies what I suspected. Since there is an operational incompatibility, the upgrade procedure NOT JUST THE DOCUMENTATION should warn people that there needs to be an ANALYZE/DISK_STRUCTURE performed.

Since it might cause existing code to malfunction, I would almost go so far as to say it that MOUNT, by default, should check to see if the volume has been updated. If not, there should be an automatic update pass. In deference to the time involved on large volumes, perhaps this should be controlled by a SYSGEN parameter or system/exec mode logical name.

My reasoning is that changes which would cause previously functioning code to malfunction on upgrade are an extremely serious issue.

- Bob Gezelter, http://www.rlgsc.com