C symlink() and unlink() problem

[Jean-François Piéronne]

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
#include
#include
#include
main() {
char buf[200];
int len ;
symlink("The link value", "./s");
perror("symlink");
errno = 0;
len = readlink("./s", buf, 100);
perror("readlink");
errno = 0;
buf[len] = 0;
puts(buf);
unlink("./s");
perror("unlink");
}
$ 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.

If I define DECC$POSIX_COMPLIANT_PATHNAMES to 1
then the symbolic link is correctly deleted.
But, this logical is not really useful due to current restriction.

Any idea?

Thanks,


JF

[John Gillings]

JF,

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

[Jean-François Piéronne]

John,

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

Thanks,

JF

[Duncan Morris]

JF,

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

unlink("sys$sysdevice:[duncan]S.;1");

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.

Regards,

Duncan

[Craig A Berry · Accepted solution]

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:

http://public.activestate.com/cgi-bin/perlbrowse/f/vms/vms.c

[Jean-François Piéronne]

Ducan, thanks for the test.

Craig, this is exactly what I have done:
http://hg.vmspython.dyndns.org/vmspython/rev/4c64e74e4c80

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,

JF