Bug #22157 for ExtUtils-Install: RE: ExtUtils::Install::_can_write_dir bug (was RE: XML::Parser XML::DOM XML::XSLT)

Wed Oct 18 01:09:50 2006 friedberg [...] exs.esb.com - Ticket created

CC:	<vmsperl [...] perl.org>, <bug-ExtUtils-Install [...] rt.cpan.org>
Subject:	RE: ExtUtils::Install::_can_write_dir bug (was RE: XML::Parser XML::DOM XML::XSLT)
Date:	Wed, 18 Oct 2006 01:09:21 -0400
To:	<schwern [...] pobox.com>, "Craig A. Berry" <craigberry [...] mac.com>
From:	"Carl Friedberg" <friedberg [...] exs.esb.com>

Hi, Sorry, I'll take responsibility for lack of reporting. I found this when trying to install several modules after I installed the latest version of MakeMaker. Craig figured out what the problem might have been; but his patch did not pass all the mm tests. This bug report refers to failed attempts to install XML::XSLT I have not previously filed any bug reports for perl, except by posting here on VMS Perl. I am sending a copy of this e-mail to report the bug, as I don't care to register for a BitCard. The big picture: (on VMS): mmk install fails, if the install script needs to write into the top level directory perl_root:[utils]. This happens with both 5.9.4 and 5.8.6, running on OpenVMS 7.3-2. From my original post to VMSPerl on Mon 9/25/2006 2:27 PM: "Finally I built XML::XSLT, and all tests passed. Unfortunately, I can not get XML::XSLT installed (from the SYSTEM account), neither with MMK, nor with MMS. Here's the mms output: mms /list=xlst_install.log install !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ERROR: Can't create 'perl_root:[utils]' Unknown Error !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! at -e line 1 %SYSTEM-F-ABORT, abort %MMS-F-ABORT, For target PURE_SITE_INSTALL, CLI returned abort status: %X0000002C. -SYSTEM-F-ABORT, abort I have attached the mms output xslt_install.log (I changed the name from the mangled typo above). I used MMK throughout the above, and it gave the exact same error; I now tried MMS, just in case (and I knew how to log the actions). -------------------------------------------------------------------- I have attached the log file. Carl Friedberg Comet & Company 165 William St 9 NY NY 10038 www.comets.com (212) 233-5470 Show quoted text

> -----Original Message----- > From: Michael G Schwern [mailto:schwern@gmail.com] > Sent: Tuesday, October 17, 2006 11:50 PM > To: Craig A. Berry > Cc: Carl Friedberg; vmsperl@perl.org > Subject: Re: ExtUtils::Install::_can_write_dir bug (was RE: > XML::Parser XML::DOM XML::XSLT) > > Craig A. Berry wrote:

> > At 9:02 AM -0400 9/29/06, Carl Friedberg wrote:

> >> I've found the deadly combination: MakeMaker 6.30-2, VMS

> 7.3-2, Perl

> >> 5.8.6, and a perl module with a script (which gets put

> into perl_root:[utils].

> > > > The problem would happen for anything installed in the top level of > > the install target. The bug is in

> ExtUtils::Install::_can_write_dir.

> > The offending line (well, the root of the trouble), is: > > > > > > my @dirs=File::Spec->splitdir(File::Spec->rel2abs($dir)); > > > > > > splitdir, as its name implies, only operates on directories. > > rel2abs, on a platform that has the notion of disk volume that is > > syntactically different from a directory, includes the

> volume as well

> > as directories in its result. The function ends up calling

> catdir on

> > the results of splitdir, and the result of

> catdir(splitdir('disk:[dir]'))

> > is undefined: > > > > $ perl -"MFile::Spec" -e "print defined

> File::Spec->catdir(File::Spec->splitdir('disk:[dir]')) ? 1 : 0;"

> > 0 > > > > > > Possibly just replacing splitdir/catdir in this function with > > splitpath/catpath would work. I'll try it and post again.

> > ExtUtils::Install's bug tracker is here: > http://rt.cpan.org/Public/Dist/Display.html?Name=ExtUtils-Install > > I don't see this bug reported. If you don't tell the author, > he'll never know there's a problem. Posting to vmsperl > doesn't count, most CPAN authors don't read it. And don't > wait to have a patch to report a bug. >

Download xslt_install.log
application/octet-stream 4k

Message body not shown because it is not plain text.

Fri Oct 20 00:11:24 2006 cberry [...] cpan.org - Correspondence added

From:

cberry [...] cpan.org

On Wed Oct 18 01:09:50 2006, friedberg@exs.esb.com wrote: Show quoted text

> I found this when trying to install several modules after I installed > the latest version of MakeMaker. Craig figured out what the problem > might have been; but his patch did not pass all the mm tests.

My original patch, which was not included in Carl's report, solved his immediate problem, but as he notes introduced some other failures in the ExtUtils tests. The patch against blead@29051 attached here resolves those problems. All ExtUtils tests pass on VMS after application of this patch. I have not tested on other platforms.

--- lib/ExtUtils/Install.pm;-0 Sun Jul 2 11:35:05 2006 +++ lib/ExtUtils/Install.pm Thu Oct 19 22:25:29 2006 @@ -431,11 +431,12 @@ sub _can_write_dir { return unless defined $dir and length $dir; - my @dirs=File::Spec->splitdir(File::Spec->rel2abs($dir)); + my ($vol, $dirs, $file) = File::Spec->splitpath(File::Spec->rel2abs($dir)); + my @dirs = File::Spec->splitdir($dirs); my $path=''; my @make; while (@dirs) { - $dir=File::Spec->catdir(@dirs); + $dir=File::Spec->catpath($vol, @dirs, ''); next if ( $dir eq $path ); if ( ! -e $dir ) { unshift @make,$dir;

Fri Oct 20 00:11:26 2006 The RT System itself - Status changed from 'new' to 'open'

Fri Oct 20 14:12:05 2006 friedberg [...] exs.esb.com - Correspondence added

Subject:	RE: [rt.cpan.org #22157] RE: ExtUtils::Install::_can_write_dir bug (was RE: XML::Parser XML::DOM XML::XSLT)
Date:	Fri, 20 Oct 2006 14:11:33 -0400
To:	<bug-ExtUtils-Install [...] rt.cpan.org>
From:	"Carl Friedberg" <friedberg [...] exs.esb.com>

Craig, Passed all tests on 5.9.4, OpenVMS 7.3-2 on AlphaServer Passed all tests on 5.8.6, OpenVMS 7.3-2 on AlphaServer [to install, I had to first copy install.pm, by hand, to perl_root:[lib.extutils]. Then, mmk install worked. Just a bootstrap...only needed if you already installed the just previous version, as I had done. Hmmm, that installed because the version before was used to do the install. gark. Carl Friedberg friedberg@comets.com www.comets.com Show quoted text

> -----Original Message----- > From: Craig A. Berry via RT [mailto:bug-ExtUtils-Install@rt.cpan.org] > Sent: Friday, October 20, 2006 12:11 AM > To: Carl Friedberg > Subject: [rt.cpan.org #22157] RE: ExtUtils::Install::_can_write_dir > bug (was RE: XML::Parser XML::DOM XML::XSLT) > > > <URL: http://rt.cpan.org/Ticket/Display.html?id=22157 > > > On Wed Oct 18 01:09:50 2006, friedberg@exs.esb.com wrote: >

> > I found this when trying to install several modules after I

> installed

> > the latest version of MakeMaker. Craig figured out what the problem > > might have been; but his patch did not pass all the mm tests.

> > My original patch, which was not included in Carl's report, solved > his immediate problem, but as > he notes introduced some other failures in the ExtUtils tests. The > patch against blead@29051 > attached here resolves those problems. All ExtUtils tests pass on > VMS after application of this > patch. I have not tested on other platforms.

Sat Apr 07 13:57:41 2007 cberry [...] cpan.org - Correspondence added

I just tried 1.41_03, which has a version of my patch in it, but not one that works. It does a catdir on the directory portion, which on VMS creates a relative directory spec, and then it does a catpath joining a volume spec to that relative directory, so you end up with a nonsense path that is part absolute and part relative. The patch below restores what I had originally submitted. Perhaps there are other problems with it I'm not aware of, but at least it keeps us from testing the writability of directories whose existence is logically impossible. But the whole approach is in my opinion flawed for a couple of reasons. The excessive splitting apart and rejoining of pieces of path names is inherently fragile and should be avoided if at all possible. And the reason we are doing it is so we can second guess mkpath() and predict what it will or won't do and why it will or won't do it. Reproducing and supplementing the internal logic of mkpath() is another inherently fragile process. We are being given a path. mkpath() knows how to operate on paths. If robustness is important, we should take the path, hand it off to mkpat(), handle any errors it throws at us, and leave it at that. Instead I'm seeing installations that fail merely because we are trying too hard to predict whether they can succeed. --- perl_root:[lib.ExtUtils]Install.pm;-1 Sat Apr 7 11:22:34 2007 +++ perl_root:[lib.ExtUtils]Install.pm Sat Apr 7 11:41:55 2007 @@ -436,8 +436,7 @@ sub _can_write_dir { my $path=''; my @make; while (@dirs) { - $dir = File::Spec->catdir(@dirs); - $dir = File::Spec->catpath($vol,$dir,""); + $dir = File::Spec->catpath($vol,@dirs,""); next if ( $dir eq $path ); if ( ! -e $dir ) { unshift @make,$dir;

Sat Jul 07 11:16:30 2007 yves [...] cpan.org - Correspondence added

On Sat Apr 07 13:57:41 2007, CBERRY wrote: Show quoted text

> I just tried 1.41_03, which has a version of my patch in it, but not > one that works. It does a > catdir on the directory portion, which on VMS creates a relative > directory spec, and then it > does a catpath joining a volume spec to that relative directory, so > you end up with a > nonsense path that is part absolute and part relative. The patch > below restores what I had > originally submitted. Perhaps there are other problems with it I'm > not aware of, but at least it > keeps us from testing the writability of directories whose existence > is logically impossible. > > But the whole approach is in my opinion flawed for a couple of > reasons. The excessive > splitting apart and rejoining of pieces of path names is inherently > fragile and should be > avoided if at all possible. And the reason we are doing it is so we > can second guess mkpath() > and predict what it will or won't do and why it will or won't do it. > Reproducing and > supplementing the internal logic of mkpath() is another inherently > fragile process. We are > being given a path. mkpath() knows how to operate on paths. If > robustness is important, we > should take the path, hand it off to mkpat(), handle any errors it > throws at us, and leave it at > that. Instead I'm seeing installations that fail merely because we > are trying too hard to > predict whether they can succeed.

Can you please try 1.41_04 (which I just uploaded to PAUSE) and see if it works out ok? BTW, the whole idea of this check is to prevent half installs clobbering and older one due to silly permission checks. It could probably be improved however. Sorry for the lag on doing this... Yves

Sat Jul 07 11:16:35 2007 yves [...] cpan.org - Given to YVES

Fri Jul 13 12:25:16 2007 yves [...] cpan.org - Correspondence added

Ive been informed this is resolved by 1.41_04 so im closing the ticket. thanks.

Fri Jul 13 12:25:18 2007 yves [...] cpan.org - Status changed from 'open' to 'resolved'