- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Any known problems with SYMLINKS ?
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-23-2011 05:05 AM - last edited on тАО08-25-2011 02:34 PM by Kevin_Paul
тАО02-23-2011 05:05 AM - last edited on тАО08-25-2011 02:34 PM by Kevin_Paul
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-23-2011 05:08 AM
тАО02-23-2011 05:08 AM
Re: Any known problems with SYMLINKS ?
>>> 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$
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-23-2011 05:10 AM
тАО02-23-2011 05:10 AM
Re: Any known problems with SYMLINKS ?
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-23-2011 06:09 AM
тАО02-23-2011 06:09 AM
Re: Any known problems with SYMLINKS ?
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-23-2011 06:57 AM
тАО02-23-2011 06:57 AM
Re: Any known problems with SYMLINKS ?
>> 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-23-2011 01:33 PM
тАО02-23-2011 01:33 PM
Re: Any known problems with SYMLINKS ?
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-23-2011 01:45 PM
тАО02-23-2011 01:45 PM
Re: Any known problems with SYMLINKS ?
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-23-2011 01:58 PM
тАО02-23-2011 01:58 PM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-23-2011 02:01 PM
тАО02-23-2011 02:01 PM
Re: Any known problems with SYMLINKS ?
The relevant release notes are at:
http://h30266.www3.hp.com/odl/i64os/opsys/vmsos84/6677/6677pro_gen.html#symlinks_imp
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-23-2011 05:30 PM
тАО02-23-2011 05:30 PM
Re: Any known problems with SYMLINKS ?
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