topic Re: Any known problems with SYMLINKS ? in Operating System - OpenVMS

Any known problems with SYMLINKS ?

P Muralidhar Kini — Thu, 25 Aug 2011 21:34:59 GMT

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

Re: Any known problems with SYMLINKS ?

P Muralidhar Kini — Wed, 23 Feb 2011 13:08:40 GMT

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$

Re: Any known problems with SYMLINKS ?

P Muralidhar Kini — Wed, 23 Feb 2011 13:10:03 GMT

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.

Re: Any known problems with SYMLINKS ?

Hoff — Wed, 23 Feb 2011 14:09:31 GMT

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.

Re: Any known problems with SYMLINKS ?

P Muralidhar Kini — Wed, 23 Feb 2011 14:57:47 GMT

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

Re: Any known problems with SYMLINKS ?

Robert Gezelter — Wed, 23 Feb 2011 21:33:20 GMT

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

Re: Any known problems with SYMLINKS ?

Steven Schweda — Wed, 23 Feb 2011 21:45:00 GMT

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

Re: Any known problems with SYMLINKS ?

Craig A Berry — Wed, 23 Feb 2011 21:58:22 GMT

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

Re: Any known problems with SYMLINKS ?

Craig A Berry — Wed, 23 Feb 2011 22:01:08 GMT

Bob,

The relevant release notes are at:

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

Re: Any known problems with SYMLINKS ?

Robert Gezelter — Thu, 24 Feb 2011 01:30:54 GMT

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

Re: Any known problems with SYMLINKS ?

Shriniketan Bhagwat — Thu, 24 Feb 2011 03:18:21 GMT

Hi Steven Schweda,

Please provide more information on the issues you are facing with BACKUP. Does the file reporting BACKUP-E-OPENIN error is a symlink file? It would be good, if we have some kind of reproducer to reproduce the issue locally.

Regards,
Ketan

Re: Any known problems with SYMLINKS ?

Shriniketan Bhagwat — Thu, 24 Feb 2011 03:26:35 GMT

Hi,

One more info.

BACKUP treats symlinks as ordinary files. They are saved and restored as is, but are not followed. Consequently, BACKUP will not follow symlinks in its searching of directory paths either. This is how the current BACKUPâ s designed WRT symlink.

Regards,
Ketan

Re: Any known problems with SYMLINKS ?

P Muralidhar Kini — Thu, 24 Feb 2011 03:36:59 GMT

Steven,

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

This problem is seen with V83 version.
However the SYMLINK redesign in V84 has fixed this problem. I have attached the logs of BACKUP/COMPARE command with SYMLINK on a V83 and V84 system.

Regards,
Murali

Re: Any known problems with SYMLINKS ?

Robert Gezelter — Thu, 24 Feb 2011 10:56:57 GMT

Ketan,

Re: BACKUP and symlinks

On the question of following symlinks during a BACKUP operation, arguments can be made for/against.

However, with all due respect (WADR) there is a need both ways for appropriate warnings. For example:

- symlink included, but not followed:

BACKUP-W-SYMNOTFLW Symbolic link included in file specifier; not followed.

- symlink included, but followed:

BACKUP-W-FILRESTOUT File restored outside specifier from symbolic link

The problem here is compliance and auditing. If someone in all innocence, attempts a backup, and because of a symbolic link does not actually backup the data, there could be a problem at a later date, with potentially serious consequences. Conversely, if something is restored outside of the expected path, BACKUP needs to report it so it can be logged for posterity.

Consider the corporate scenarios of what happens when someone attempts to preserve/restore a directory clade before/after an update or test. If a file that would be expected to be referenced is preserved or not preserved can be a source of serious problems. In the pressure of the moment, the semantic distinction between having a file and only having a symlink to a file can be lost. This can cause a great deal of confusion in what is often a time of high stress. Human factors requires clarity for accurate decision making.

This is similar to the classic programming problem of damaging an input variable because it is call-by-reference instead of call-by-value. People who work in several different languages, each with its own default behaviors (e.g., FORTRAN/C) are familiar with the symptoms of this problem.

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

Re: Any known problems with SYMLINKS ?

Shriniketan Bhagwat — Thu, 24 Feb 2011 11:22:35 GMT

Hi Bob,

Thanks for the input. I agree with you. It is better to notify the user than being silent.

Regards,
Ketan

Re: Any known problems with SYMLINKS ?

Hoff — Thu, 24 Feb 2011 14:14:49 GMT

What happens when you restore one of these BACKUP savesets, particularly when the saveset is populated with some unknown number of symlinks?

Do you get to locate and resolve an unknown number of now-dangling symlinks to location(s) that may not or do not exist in the restored configuration?

I'm guessing I now have to post-process the restored volume, looking for and updating or removing these symlinks.

Then there are the potentially very obscure results of restarting an application on a restored volume on a backup server, and the application encounters a latent symlink pointing off into hyperspace. Particularly when you're in crunch-mode working to get the application back online.

Re: Any known problems with SYMLINKS ?

Craig A Berry — Thu, 24 Feb 2011 15:03:29 GMT

The DIRECTORY command got the negatable /SYMLINK qualifier; it seems to me the BACKUP command is even more in need of fine-grained file selection. It's not immediately obvious to me what the default should be, though, nor that it should be the same for every type of backup. /PHYSICAL and /IMAGE should probably not follow links by default.

And then there is the problem of what to do on restore when the file the symlink points to belongs in a place that doesn't exist on the restore target (such as on another volume that isn't there).

I can imagine designing something workable would be non-trivial. But doing nothing doesn't seem entirely workable either.

Re: Any known problems with SYMLINKS ?

P Muralidhar Kini — Thu, 24 Feb 2011 16:48:20 GMT

Robert,

>> Thank you for the citation, I did not have the time when I posted that
>> comment to dig through things for the citation.
Thanks Craig for the link.
Yes, the information about the SYMLINK feature and the need to run VERIFY from
V84 node to convert the SYMLINK created on V83 node in to a format compatible
with V84 node is mentioned in the OPenVMS V84 Release notes.

>> 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.
Yes, thats a good suggestion.
Something like the upgrade procedure should display a message as to what
needs to be done in case there are SYMLINKS already created from an pre V84
system.

I will keep these things in mind. Something to consider when doing any similar
kind of work in the future.

>> - symlink included, but not followed:
>> BACKUP-W-SYMNOTFLW Symbolic link included in file specifier; not followed.
>>
>> - symlink included, but followed:
>> BACKUP-W-FILRESTOUT File restored outside specifier from symbolic link
>>
>> The problem here is compliance and auditing. If someone in all innocence,
>> attempts a backup, and because of a symbolic link does not actually
>> backup the data, there could be a problem at a later date, with potentially
>> serious consequences
Thats a excellent suggestion.
Currently i think the BACKUP copies only the SYMLINK and does not report any
message indicating whether the target of SYMLINK is copied or not.
Displaying a message about this would alert the system administator, so that he
can take the necessary action. If the target also gets copied as a part of the
BACKUP then its ok, otherwise the symlink would be pointing to nothing (or to
a wrong file that already exisits) when it gets restored at some future date.

I am sure Ketan would have made a note of this in his to-do list for BACKUP utility.
I will check with him anyways.

Hoff,
>> What happens when you restore one of these BACKUP savesets, particularly
>> when the saveset is populated with some unknown number of symlinks?
when taking a BACKUP, the SYMLINKS are treated as ordinary files and are
copied as it is. i.e. the target is not followed. When BACKUP saveset is restored,
the SYMLINKS would be created on the disk.

* If the target happened to be copied as a part of the BACKUP saveset then the
restored SYMLINK would work. If not then the following is possible

* It may happen that there is some other file already present which corresponds
to the same path as referenced by the SYMLINK.
In this case the acessing the SYMLINK would end up accessing that file.
or
* SYMLINK would be dangling. Its link corresponds to a file that was not restored
as a part of the BACKUP and hence does not exist. Access to the SYMLINK would fail.

>> Do you get to locate and resolve an unknown number of now-dangling
>> symlinks to location(s) that may not or do not exist in the restored
>> configuration? I'm guessing I now have to post-process the restored volume,
>> looking for and updating or removing these symlinks.
Yes, i guess thats the way. Looks like a lot of manual work is involved here.
Need to locate all the symlinks that got restored. Check their target (which could
again be another symlink). The target may not be present in the restored
configuration as the target could reside on some other disk and so on.

>> Then there are the potentially very obscure results of restarting an application
>> on a restored volume on a backup server, and the application encounters a
>> latent symlink pointing off into hyperspace.
>> Particularly when you're in crunch-mode working to get the application back
>> online
Yes, thats correct. These are some excellent scenarios that we need to make a
note when talking about BACKUP and SYMLINKS. I am not sure if this is
documented, if not then i guess it would be worth documenting it.

Thanks everyone for the comments. There are so many things to consider when
we look from the customers perspective. Good learning.

Regards,
Murali

Re: Any known problems with SYMLINKS ?

Hoff — Thu, 24 Feb 2011 18:00:15 GMT

An update to BACKUP /INTERCHANGE might be a reasonable way to cause BACKUP to flag or to strip off all off-disk or out-of-purview of the BACKUP symlinks. It already does something sort-of similar, stripping ACLs.

Re: Any known problems with SYMLINKS ?

Robert Gezelter — Fri, 25 Feb 2011 00:19:51 GMT

Murali (and Ketan),

Concerning my earlier comment about ANALYZE/DISK_STRUCTURE (aka VERIFY).

If I may, a suggestion for a standing REQUIREMENT for symlinks, and any similar structural change that will result in a forward incompatibility:

- a command procedure to be run before (emphasis: BEFORE) upgrading to ensure readiness for upgrade.

- the command procedure should have two modes: identify and update. Identify merely lists the items that would need to be changed.

This will prevent errors leading to numerous support calls.

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