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. 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. >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. >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. Yes, it most certainly is creating a symbolic link. Whether it's valid or not, readlink() has no trouble following it: $ perl -e "print readlink 'linktest';" [._ptrslt_._path_._to_._a_._dir_] $ dir/full linktest Directory D0:[CRAIG.perl.t] LINKTEST.;1 File ID: (72383,81,0) Size: 1/33 Owner: [CAB,CRAIG] Created: 29-NOV-2007 10:27:28.72 Revised: 29-NOV-2007 10:27:28.79 (1) Expires: <None specified> Backup: <No backup recorded> Effective: <None specified> Recording: <None specified> Accessed: 29-NOV-2007 10:27:28.94 Attributes: 29-NOV-2007 10:27:28.79 Modified: 29-NOV-2007 10:27:28.77 Linkcount: 1 File organization: Special: symbolic link Link Contents: [._ptrslt_._path_._to_._a_._dir_] Shelved state: Online Caching attribute: Writethrough File attributes: Allocation: 33, Extend: 0, Global buffer count: 0, No version limit RMS attributes: None Journaling enabled: None File protection: System:RWED, Owner:RWED, Group:RE, World: Access Cntrl List: None Client attributes: None Total of 1 file, 1/33 blocks. -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
