HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
Operating System - OpenVMS
Showing results for 
Search instead for 
Did you mean: 

C symlink() and unlink() problem

Go to solution
Jean-François Piéronne
Trusted Contributor

C symlink() and unlink() problem

Using Mercurial, 8.3 VMS, ACRTL V300 on an Itanium I have found that C unlink() don't work on a symbolic link, I have write a small C reproduced:

$ dir /dat s
%DIRECT-W-NOFILES, no files found
$ ty foo.c
main() {
char buf[200];
int len ;
symlink("The link value", "./s");
errno = 0;
len = readlink("./s", buf, 100);
errno = 0;
buf[len] = 0;
$ r foo
symlink: no such file or directory
readlink: error 0
The link value
unlink: no such file or directory
sg1> dir/dat s

Directory SYS$SYSROOT:[SYSMGR.python_tmp]

S.;1 -> The link value
29-AUG-2007 23:26:02.86

Total of 1 file.
So The link is correctly created but the unlink() routine is unable to delete it.

I don't have any 8.3 alpha system so I can't test on such platform.

then the symbolic link is correctly deleted.
But, this logical is not really useful due to current restriction.

Any idea?



John Gillings
Honored Contributor

Re: C symlink() and unlink() problem


If you think it's a bug, please lodge a formal report with HP.

Send them your reproducer, plus transcripts of the run, clearly pointing out the behaviour observed, and the behaviour expected. Once they've reproduced your symptoms, they can try and figure out if it's a bug (never easy in this territory!)

A crucible of informative mistakes
Jean-François Piéronne
Trusted Contributor

Re: C symlink() and unlink() problem


> If you think it's a bug, please lodge a formal report with HP.

This is what I generally do, but the before doing this I would like to be sure it's a bug, for example it's may be a expected behavior if some DECC$* feature is not enable and there are so many...

I would like to know if someone has encountered (and solve) this problem.


Duncan Morris
Honored Contributor

Re: C symlink() and unlink() problem


I can confirm that Alpha 8.3 shows the same behavious with C V7.1.

It appears to relate to the ambiguity resulting from the filename "./s".

When the file doesn't exists (at the stage of symlink), then CRTL is treating it as a file specification - so we get the S.;1 name.

However, when the file spec is handled for unlink, it is coming up with a non-existent filename.

If you force the filename to a VMS style spec, like this


then the unlink works.

So I would agree with you that it seems to be a problem with the interpretation of the "./S" specification between symlink and unlink.


Craig A Berry
Honored Contributor

Re: C symlink() and unlink() problem

John Malmberg has recently added some code to Perl for this situation. His comment says:

* The CRTL for 8.3 and later can create symbolic links in any mode,
* however in 8.3 the unlink/remove/delete routines will only properly handle
* them if one of the PCP modes is active.

So he rolled his own in terms of SYS$ERASE. You can look for Perl_kill_file() and rms_erase() here:

Jean-François Piéronne
Trusted Contributor

Re: C symlink() and unlink() problem

Ducan, thanks for the test.

Craig, this is exactly what I have done:

I try to use unlink and if it failed then I fall back to sys$erase.

So it seem it is a bug in the CRTL.

I just found that getnameinfo is buggy in TCPIP 5.6 and fix this in a forthcoming Python kit...

Thanks to all,