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