Craig A. Berry wrote:
At 8:44 AM -0600 11/29/07, John E. Malmberg wrote:
I just applied the File::Spec::VMS patch, but I think that the
cwd.t/Cwd.pm one has been applied by Craig as #32053 (or I'm confused.)
Can you confirm ?
So I think that what is now in the core is what should be released on CPAN.
After fiddling with this a bit, I concur. Keep what's in the core
now for 5.10. John's new stuff is promising but just isn't ready
yet. I keep stepping on bugs in the new infrastructure in vms.c and
the changes to Cwd.pm introduce new test failures when applied to
blead. So I think we need a release from Ken that matches what's in
blead. Then, if he wishes, he can turn around and do a _01 release
with all the new stuff put back in.
Sorry for the mess.
Change #32053 is wrong. It does not implement symbolic links for
VMS, it just changes things to look like the test passes on VMS.
>> Sorry to be the bearer of bad news. I should have looked at it
>> more carefully when it was applied.
[reordered for clarity]
>> With out that patch, the cwd.t is not creating a valid symbolic
link, >> so the test should fail on VMS instead of passing like it does now.
There was a bug in what it returned when it failed. It looks like your
change fixes that.
Still it is telling you that the cwd.t in blead is passing an a symbolic
link that can not be resolved to a valid path, so it should fail on the
returned match.
> Yes, it most certainly is creating a symbolic link. Whether it's
> valid or not, readlink() has no trouble following it:
readlink() does not follow symbolic links. readlink() just reads the
contents.
While a symbolic link normally contains a path, there is no rule that it
must contain a path, and it can contain anything that you want to put
into it. If what you put in is not a valid path, realpath() can not
resolve it.
Just like VMS logical names can be used to contain values that are not
pathnames.
> $ perl -e "print readlink 'linktest';"
> [._ptrslt_._path_._to_._a_._dir_]
>
> $ dir/full linktest
Wrong test.
Try dir [.linktest]
You should get a listing of a directory, or a no files found.
With the symbolic link above, I get -RMS-E-DNF, directory not found.
Now do this:
create goodlink/symlink="_ptrslt_/_path_/_to_/_a_/_dir_"
dir [.goodlink]
%DIRECT-W-NOFILES, no files found.
As far as symlink handling, all it does is make _vms_abs_path follow
identical logic to what _fast_abs_path does. Specifically, it just
uses C<-l> and C<readlink>, both of which appear to be working fine.
I tested this pretty carefully before committing it and again just
now and I see no problems with it.
It appears that we need to add a test to show what happens when you ask
for the absolute path of a symbolic link that does not resolve to a real
path.
It looks like the difference between fast_abs_path and abs_path is that
fast_abs_path does not verify that the actual symbolic link targets exist.
The fast_abs_path algorithm is actually slower on VMS than the new
routines that return the vms_realpath() or vms_realfile().
The vms_realfile() is actually the fastest. The CRTL realpath does the
same algorithm that Perl does to search for the elements of the path.
The vms_realfile() just quickly looks up the what in Unix terms is the
primary link to the file.
Do we need a fast_abs_path routine that is just as unsafe as UNIX, and
is also slower than the normal abs_path routine?
Prior to patch 32474, VMS did not have a C<realpath> equivalent
method, and could not convert paths with symbolic links in them to
absolute paths that did not contain a symbolic link.
The cwd.pm from the Ken's pathtools is the correct one now. Ken did
not pick up the required change to cwd.t to make the test pass on VMS.
It is only different in some formatting issues from the patch I
submitted to blead cwd.pm. So taking the cwd.pm from Ken's current
pathtools may be the best. I do not have a patch submitted for that.
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.
That is why I made the pod updates.
Because a symbolic link can contain random text instead of a valid link,
we should not automatically convert the symbolic link target to Unix syntax.
-John
[EMAIL PROTECTED]
Personal Opinion Only
