Peter Prymmer <[EMAIL PROTECTED]> wrote on 03/07/2006 11:42:38 PM:
> Sorry but I have made no progress on this problem. I am concerned.
I now suspect that there is a VMS specific bug in File::Path::mkpath.
If I add a diagnostic print statement to that module like so:
$ gdiff -u [.lib.file]path.pm [.lib.file]path.pm;1
--- [.lib.file]path.pm Wed Mar 8 16:25:15 2006
+++ [.lib.file]path.pm;1 Wed Sep 7 10:59:46 2005
@@ -168,7 +168,6 @@
next if -d $path;
my $parent = File::Basename::dirname($path);
unless (-d $parent or $path eq $parent) {
-print "\$parent = >$parent<, \$path = >$path<\n";
push(@created,mkpath($parent, $verbose, $mode));
}
print "mkdir $path\n" if $verbose;
Then when I run "mmk install" I see:
$parent = >/perl_root<, $path = >/perl_root/000000<
$parent = >/perl_root<, $path = >/perl_root/000000<
$parent = >/perl_root<, $path = >/perl_root/000000<
$parent = >/perl_root<, $path = >/perl_root/000000<
and clearly too many things are being pushed onto the @created array.
While I do not yet have a fix I can workaround the problem
if I issue the shell command:
create/dir dka300:[user.pprymmer.bleed_root]
prior to running "mmk install" from within dka300:[user.pprymmer.bleed].
Even with that workaround there are some lingering problems
with chmod() calls to files that apparently
are not copied into my new perl_root (but really are).
For example during the course of the run of "mmk install" I see:
/perl_root/lib/archive/tar/constant.pm
/perl_root/lib/archive/tar/file.pm
/perl_root/lib/archive/tar/bin/ptar.
Couldn't chmod 444 /perl_root/lib/VMS_AXP/5_9_4/auto/compress/zlib: no
such file or directory
then when that finishes I see:
$ dir/date/size perl_root:[lib.VMS_AXP.5_9_4.auto.compress]zlib*.*
Directory PERL_ROOT:[LIB.VMS_AXP.5_9_4.AUTO.COMPRESS]
ZLIB.DIR;1 1 8-MAR-2006 16:50:53.18
ZLIB.EXE;1 237 21-JUN-2005 13:31:04.51
Total of 2 files, 238 blocks.
Peter Prymmer