Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Any known problems with SYMLINKS ?

 
P Muralidhar Kini
Honored Contributor

Any known problems with SYMLINKS ?

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

Let There Be Rock - AC/DC
28 REPLIES 28
P Muralidhar Kini
Honored Contributor

Re: Any known problems with SYMLINKS ?

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$
Let There Be Rock - AC/DC
P Muralidhar Kini
Honored Contributor

Re: Any known problems with SYMLINKS ?

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.
Let There Be Rock - AC/DC
Hoff
Honored Contributor

Re: Any known problems with SYMLINKS ?

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

Re: Any known problems with SYMLINKS ?

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
Let There Be Rock - AC/DC
Robert Gezelter
Honored Contributor

Re: Any known problems with SYMLINKS ?

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

Re: Any known problems with SYMLINKS ?

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

Re: Any known problems with SYMLINKS ?

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

Re: Any known problems with SYMLINKS ?

Robert Gezelter
Honored Contributor

Re: Any known problems with SYMLINKS ?

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
Shriniketan Bhagwat
Trusted Contributor

Re: Any known problems with SYMLINKS ?

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
Shriniketan Bhagwat
Trusted Contributor

Re: Any known problems with SYMLINKS ?

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
P Muralidhar Kini
Honored Contributor

Re: Any known problems with SYMLINKS ?

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
Let There Be Rock - AC/DC
Robert Gezelter
Honored Contributor

Re: Any known problems with SYMLINKS ?

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
Shriniketan Bhagwat
Trusted Contributor

Re: Any known problems with SYMLINKS ?

Hi Bob,

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

Regards,
Ketan
Hoff
Honored Contributor

Re: Any known problems with SYMLINKS ?

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.
Craig A Berry
Honored Contributor

Re: Any known problems with SYMLINKS ?

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.
P Muralidhar Kini
Honored Contributor

Re: Any known problems with SYMLINKS ?

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
Let There Be Rock - AC/DC
Hoff
Honored Contributor

Re: Any known problems with SYMLINKS ?

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.
Robert Gezelter
Honored Contributor

Re: Any known problems with SYMLINKS ?

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
P Muralidhar Kini
Honored Contributor

Re: Any known problems with SYMLINKS ?

Hoff,
>> 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.
Your suggestion seems to be like,
If SYMLINK and target come under the purview of the BACKUP then include
the SYMLINK in the backup & display a message indicating the same.
If not then exclude the SYMLINK from the backup & display a message
indicating the same.

Sounds reasonsble as backing up the SYMLINK without the target would not
be of much use as the SYMLINK wont be functional once it gets restored in
the future.

How about a scenario where, SYMLINK is on Disk1 and its target is on Disk2.
If BACKUP's were per disk, SAVESET1 for disk1 and SAVESET2 for disk2.
At a future date, both SAVESET1 and SAVESET2 are restored.
SYMLINKS restored in this manner would work.
So i guess the option to include/exclude a symlink which does not come under
the purview of the BACKUP can be made controllable.

Robert,
>> - 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.
VERIFY on V84 does this job. But for a customer who is yet to upgrade from
pre V84 to V84, he would not have the VERIFY for V84. He would have to do the
upgrade first and then probably run the VERIFY to get the pre v84 SYMLINKS
repaired.

you are suggesting that, customers would benefit more if there is a means by
which the compatibility stuff can be sorted out before the upgrade (both identify
and update).

How about making the V84 VERIFY available to customers prior to upgrading.
If they could install this on the pre v84 system, then they could do both the
identify and update of the pre v84 SYMLINKS to V84 format. Once this is done
they could then proceed with the upgrade.

Regards,
Murali
Let There Be Rock - AC/DC
Robert Gezelter
Honored Contributor

Re: Any known problems with SYMLINKS ?

Murali,

Certifying that it is safe to run the 8.4 VERIFY to run on earlier systems is a start in the IMHO the correct direction. Packaging it as a "patch", possibly together with the changes to also "create" symlinks, would be even better.

The principle is straightforward. Running a ANALYZE/DISK_STRUCTURE on a significant sized storage farm is a significant project. Likely, it would be optimal to run this over time BEFORE the actual upgrade. It has already been noted that the 8.4 symlinks are fine with an 8.3 system, not vice versa.

Therefore, from the user perspective, the best order is:
- change the creation of symlinks to the 8.4 behavior (likely one or two images affected)
- run ANALYZE/DISK_STRUCTURE on all affected volumes to correct previously extant symlinks
- upgrade to 8.4.

Note that the preceding works as desired, whether or not the system is part of an OpenVMS cluster.

- Bob Gezelter, http://www.rlgsc.com
Shriniketan Bhagwat
Trusted Contributor

Re: Any known problems with SYMLINKS ?

Hi,

Extension to Muraliâ s explanation on BACKUP with SYMLINK.

There could be a scenario, where the SYMLINK is created with a specific disk name or logical. Example:

$
$ dir/link *.link

Directory SYS$SYSDEVICE:[000000]

A.LINK;1 -> /V84_DISK/000000/a.txt 1 B.LINK;1 -> /$5$DKA0/000000/a.txt 1

Total of 2 files.
$

After the image restore on the new disk, if the source disk is not mounted or the logical is not defined, then these SYSMLINKs will not work. We may have to consider all possible scenarios with BACKUP.

Regards,
Ketan
Robert Gezelter
Honored Contributor

Re: Any known problems with SYMLINKS ?

Murali,

Re-reading my posting from last night (NYC time), I realize that I was not explicit about my thoughts on this question.

The summary on my previous posting should be:

There should be a patch kit generated for 8.3 (and perhaps earlier releases) that "corrects" the behavior of symlinks to the 8.4 behavior. Following the installation of the previously described patch to the old system, it is possible to do the (potentially) laborious process of upgrading the symlinks BEFORE the upgrade to 8.4, avoiding the potential for downtime while the symlinks are upgraded.

Thus, the sequence for upgrade is:
- install patch (which will correct all future symlinks)
- perform an ANALYZE/DISK_STRUCTURE with appropriate qualifiers on each disk that has ANY symlinks
- Upgrade to 8.4

With a large, active system, there could be an extended period of time between the second and the third steps.

- Bob Gezelter, http://www.rlgsc.com
Craig A Berry
Honored Contributor

Re: Any known problems with SYMLINKS ?

Bob's proposed sequence to get 8.3 systems up to 8.4-compatible symlinks:

> - install patch (which will correct all future symlinks)
> - perform an ANALYZE/DISK_STRUCTURE with appropriate qualifiers on each disk that has ANY symlinks
> - Upgrade to 8.4

If that first step ("install patch...") means what I think it means, I'm not sure it's such a good idea. You'd basically just be moving the problem backward so you'd have v8.3 systems with the patch and v8.3 systems without the patch with two different types of symlink being produced. And depending on what the patch includes (a full backport of the v8.4 symlink implementation?) you'd have a relatively high risk patch touching delicate areas of the file system, the CRTL, perhaps various utilities, etc. And if it all works perfectly you end up with three versions of symlinks to support: v8.3, v8.3+, and v8.4. Such things have been done before, such as with XQP+ in the 5.x era (or was it 6.x?), but I'm not sure it's worth the risk.

That said, I fully agree that a better pre-upgrade option and some sort of strong encouragement in the upgrade procedure itself would be in order.