Craig A. Berry wrote:
At 7:56 PM -0600 11/29/07, John E. Malmberg wrote:
Craig A. Berry wrote:
I've tried taking what's in Ken's repository and putting it in blead
and it introduces several test failures. The most significant
problem is that the new function VMS::Filespec::vms_realname returned
garbage when passed a symbolic link. I've fixed the failure behavior
with #32556, but it still fails and is not suitable for use in core
modules just yet.
Ok, that patch makes sense. But now do you understand that test
using the vms_realname or vms_realpath is still telling you the truth
that the symbolic link is not understood by the filesystem as a
valid link.
I understand that the initial implementation of symbolic links on VMS
only supports link targets in UNIX syntax, not native syntax, which
seems odd, but that's the way it is.
At the time that I left VMS Engineering, there were no plans to
implement supporting the native syntax in symbolic links.
The expectation was that the only code that would be using the symbolic
link related routines would only be using UNIX syntax.
That could change due to customer feedback.
I could not get
VMS::Filespec::vms_realname to succeed with a symbolic link
regardless of whether the link target was in UNIX syntax (which is
supposed to be supported) or VMS syntax (which I prefer to call
unsupported, rather than invalid, as we're giving it perfectly valid
native path names).
The sanity check is to use the DCL directory command on a directory path
containing a symbolic link. If returns the correct result of either the
directory contents or a warning about the directory being empty, then
the symbolic link is a valid path.
If it fails, then the symbolic link is not a valid path, possibly for
many reasons. In addition to being in UNIX syntax, the path has to
actually exist and it needs reachable from a path in the PSX$ROOT.
The find find.t and taint.t do create symbolic links in UNIX syntax and
they are passing.
No doubt using VMS::Filespec::vms_realname will be more efficient,
more elegant, and enforce correctness more than what we have now, but
not until it's debugged and working, which unless there's an
unexpected thaw of suitable duration will be after 5.10.
What we currently have in _vms_abs_path in blead doesn't care what
syntax the link target is in as long as it's a valid path, and it
seems to me it shouldn't have to care.
It creates a situation where Perl is interpreting a pathname differently
than the host operating system, and that can cause problems down the
line. That is the type of problems that I have been running into in
getting the vmsify() and unixify() routines to properly handle ODS-5
names. And I have pointed out that this has generally caused more VMS
specific code in perl modules than should be there.
Right now, there are no VMS specific perl scripts using symbolic links,
because before 5.10 it was not available.
If you are going to leave things the way it is now, it needs a VMS
specific release note indicating that the abs_path and fast_abs_path are
currently resolving paths with symbolic link targets that the VMS itself
does not support.
I strongly believe that the correct behavior is for _vms_abs_path to
treat the path containing the symbolic link the same way as opendir() or
the DCL directory command will. If they can not process the directory,
then _vms_abs_path() should also return an empty string.
What happens on UNIX when the a symbolic link to a non-existent path is
passed to abs_path()?
VMS should behave the same way, or there needs to be documentation as to
why it does not.
Of course the past behavior of VMS appears to have been a syntax only
conversion to an absolute path, and it may not have checked to see that
the path exists like is done on UNIX.
Or, to move the problem
upstream, cwd.t (or any other Perl program) shouldn't have to know
that it needs to convert a path to UNIX syntax before symlinking to
it. We may need to address that in our symlink() wrapper at some
point.
As I have pointed out before, there is problem with having symlink()
automatically converting link targets to UNIX format.
Symbolic links do not have to have valid path names in them. Symbolic
links can be arbitrary text such as for a regular expression that looks
a bit like a VMS file specification.
While it is likely that an auto-conversion is the do-what-i-mean thing
to do, it should be a non-default option if it is ever offered.
There is still a lot of post 5.10 work that needs to be done with
getting UNIX and ODS-5 pathnames to work, so it may be that dealing with
symbolic link targets in the unsupported VMS is just part of that.
-John
[EMAIL PROTECTED]
Personal Opinion Only
