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
