Re: [.t.io]fs.t fails with hard links on OpenVMS.

[Craig A. Berry]

At 4:31 PM -0600 2/23/05, John E. Malmberg wrote:
To be more precise,

The test [.t.io]fs.t will only pass when hard links {d_link} if you set
the default RMS protections to be (O:RW, G:RW, W:RW).

I think that it is a cross platform bug where the test is assuming such
a default protection would be in place.

I see a lot of mode setting.  I think chmod on VMS sanely refuses to
override the RMS defaults with a less secure setting, but on Unix, an
explicit setting overrides the defaults if you have privilege to do
the chmod.  Someone correct me if that's not right.  Probably the
best thing to do for the test is create a temporary directory with
the necessary settings and set default to it before running the test.

Also the modules utils/c2ph.pl, x2p/pl will not allow Perl to be built
with hard link support unless they are modified.  They are trying to
create hard links from a different base filename than exists on OpenVMS.

This also requires that to support hard links in Perl that the build be
done on an ODS-5 volume with hard links enabled.

And of course the disk that the tests are run on needs to have hard links
enabled. :-)

The following makes the build complete, but someone more familiar with
what is really meant to be done may want to do something different.

$ gdiff -u -b x2p/s2p.pl_5_8_6 x2p/s2p.pl
--- x2p/s2p.pl_5_8_6Thu Feb 10 15:22:08 2005
+++ x2p/s2p.pl  Thu Feb 10 15:26:16 2005
@@ -2048,7 +2048,11 @@
 unlink 'psed';
 print Linking s2p to psed.\n;
 if (defined $Config{d_link}) {
+  if ($^O eq 'VMS') {
+link 's2p.com', 'psed';
+  } else {
   link 's2p', 'psed';
+  }
 } else {
   unshift @INC, '../lib';
   require File::Copy;

$ gdiff -u -b utils/c2ph.pl_5_8_6 utils/c2ph.pl
--- utils/c2ph.pl_5_8_6 Thu Feb 0 13:24:12 2005
+++ utils/c2ph.pl   Thu Feb 10 15:23:57 2005
@@ -1437,7 +1437,11 @@
 unlink 'pstruct';
 print Linking c2ph to pstruct.\n;
 if (defined $Config{d_link}) {
+  if ($^O eq 'VMS') {
+link 'c2ph.com', 'pstruct';
+  } else {
   link 'c2ph', 'pstruct';
+  }
 } else {
   unshift @INC, '../lib';
   require File::Copy;

I think something along the lines of the following untested patch
would be more appropriate.  We've already got a platform-independent
version of the filename we're creating, so we might as well use it:

--- x2p/s2p.PL;-0   Mon Aug 12 07:28:26 2002
+++ x2p/s2p.PL  Tue Mar  1 13:51:29 2005
@@ -2046,9 +2046,9 @@
 close OUT or die Can't close $file: $!;
 chmod 0755, $file or die Can't reset permissions for $file: $!\n;
 unlink 'psed';
-print Linking s2p to psed.\n;
+print Linking $file to psed.\n;
 if (defined $Config{d_link}) {
-  link 's2p', 'psed';
+  link $file, 'psed';
 } else {
   unshift @INC, '../lib';
   require File::Copy;

Currently the diffs in the configure.com include several patches from
Craig Berry and for enabling symbolic link support, which I do not have
done yet.

But here is the test for hard link support for 8.2.  A creative person
can make a test that works for 7.3-1 and 7.3-2.

...

 $ use64bitint = n
+$ uselargefiles = n
+$ usesymlinks = n
+$ usehardlinks


+$   config_symbols4
=|usethreads|usevmsdebug|usefaststdio|usemallocwrap|unlink_all_versions
  |uselargefiles|usehardlinks|usesymlinks|


I don't think there's any reason we would want to make hard links and
symlinks configuration options.  If we have 'em we should say so, and
if we don't we should say that too.  The definition of have 'em I
think we should use is that the APIs are present in the CRTL and they
actually work on the disk where we're building.  If you want the
features in Perl, building on an ODS-5 disk where the features are
enabled seems like a reasonable requirement.



-- 

Craig A. Berry
mailto:[EMAIL PROTECTED]

... getting out of a sonnet is much more
 difficult than getting in.
 Brad Leithauser

Re: [.t.io]fs.t fails with hard links on OpenVMS.

[John E. Malmberg]

On Tue, 1 Mar 2005, Craig A. Berry wrote:

 At 4:31 PM -0600 2/23/05, John E. Malmberg wrote:
 To be more precise,
 
 The test [.t.io]fs.t will only pass when hard links {d_link} if you set
 the default RMS protections to be (O:RW, G:RW, W:RW).
 
 I think that it is a cross platform bug where the test is assuming such
 a default protection would be in place.

 I see a lot of mode setting.  I think chmod on VMS sanely refuses to
 override the RMS defaults with a less secure setting, but on Unix, an
 explicit setting overrides the defaults if you have privilege to do
 the chmod.  Someone correct me if that's not right.  Probably the
 best thing to do for the test is create a temporary directory with
 the necessary settings and set default to it before running the test.

the chmod() calls are below the test that failed.  The umask calls
above the test succeed.

In the umask test, Perl makes two calls to umask(), one to set it to 022
with out paying attention to it's current value, and then again with
it restoring it to 0.

It appears that Perl through the CRTL or some other reason is treating a
umask of 0 as to use RMS default protection on the file.

The documentation for the CRTL shows that it should only be using the
RMS default for the umask call only if the umask call has never been made
for that program.

It looks like this needs some more investigation to find out why the
umask value of 0 is not being honored.

 Also the modules utils/c2ph.pl, x2p/pl will not allow Perl to be built
 with hard link support unless they are modified.  They are trying to
 create hard links from a different base filename than exists on OpenVMS.

 I think something along the lines of the following untested patch
 would be more appropriate.  We've already got a platform-independent
 version of the filename we're creating, so we might as well use it:

 --- x2p/s2p.PL;-0   Mon Aug 12 07:28:26 2002
 +++ x2p/s2p.PL  Tue Mar  1 13:51:29 2005
 @@ -2046,9 +2046,9 @@
  close OUT or die Can't close $file: $!;
  chmod 0755, $file or die Can't reset permissions for $file: $!\n;
  unlink 'psed';
 -print Linking s2p to psed.\n;
 +print Linking $file to psed.\n;
  if (defined $Config{d_link}) {
 -  link 's2p', 'psed';
 +  link $file, 'psed';
  } else {
unshift @INC, '../lib';
require File::Copy;

What do you need to have to get hard link support included in a future perl
release once the test issue is resolved?  It looks like the problem in the
test is with umask handling and not hardlink related, which means that the
umask issue should be reproducible with out hard link support on.

-John
[EMAIL PROTECTED]
Personal Opinion Only