Skip Menu |
 
Update: The rt.cpan.org bug tracker service is no longer shutting down.

This queue is for tickets about the File-Path CPAN distribution.

Report information
The Basics
Id: 30654
Status: resolved
Priority: 0/
Queue: File-Path

People
Owner: dland [...] cpan.org
Requestors: cberry [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 2.02
Fixed in: 2.04



Subject: [PATCH] rmtree nit when handling file in VMS syntax
MIME-Version: 1.0
X-Mailer: MIME-tools 5.418 (Entity 5.418)
X-RT-Original-Encoding: utf-8
Content-Type: multipart/mixed; boundary="----------=_1194824442-27654-1"
Content-Length: 0
Content-Type: text/plain; charset="utf8"
Content-Disposition: inline
Content-Transfer-Encoding: binary
Content-Length: 621
Download (untitled) / with headers
text/plain 621b
Sorry to always be the bearer of ugly exceptions to exceptions, but I've checked the attached into blead as #32276 to get around the following problem. When an individual file already in VMS syntax was passed to rmtree -- and that file was a relative path with at least one directory included in the name -- we were passing an invalid combination of Unix and VMS syntax to vmsify, and getting a garbage result. Basically, for the following two examples, we had to prevent the second one from happening. 'file.dat' --> vmsifiy('./file.dat') '[.foo]file.dat' --> vmsify('./[.foo]file.dat') # garbage in, garbage out
Subject: filepathfix.patch.txt
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----------=_1194824442-27654-0"
X-Mailer: MIME-tools 5.418 (Entity 5.418)
Content-Length: 0
Content-Type: text/plain; charset="utf8"
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 0
Content-Type: text/plain; charset="utf-8"; name="filepathfix.patch.txt"
Content-Disposition: inline; filename="filepathfix.patch.txt"
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: ascii
Content-Length: 747
--- lib/File/Path.pm;-0 Wed Oct 24 08:44:46 2007 +++ lib/File/Path.pm Sat Nov 10 19:50:04 2007 @@ -17,7 +17,7 @@ BEGIN { use Exporter (); use vars qw($VERSION @ISA @EXPORT); -$VERSION = '2.02'; +$VERSION = '2.02_01'; @ISA = qw(Exporter); @EXPORT = qw(mkpath rmtree); @@ -340,7 +340,9 @@ sub _rmtree { # not a directory $root = VMS::Filespec::vmsify("./$root") - if $Is_VMS && !File::Spec->file_name_is_absolute($root); + if $Is_VMS + && !File::Spec->file_name_is_absolute($root) + && ($root !~ m/(?<!\^)[\]>]+/); # not already in VMS syntax if ($arg->{safe} && ($Is_VMS ? !&VMS::Filespec::candelete($root)
MIME-Version: 1.0
X-Mailer: MIME-tools 5.418 (Entity 5.418)
Content-Disposition: inline
Message-Id: <rt-3.6.HEAD-27245-1195152195-546.30654-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf8"
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Original-Encoding: utf-8
Content-Length: 911
Download (untitled) / with headers
text/plain 911b
On Sun Nov 11 18:40:43 2007, CBERRY wrote: Show quoted text
> Sorry to always be the bearer of ugly exceptions to exceptions, but > I've checked the attached > into blead as #32276 to get around the following problem. When an > individual file already in > VMS syntax was passed to rmtree -- and that file was a relative path > with at least one directory > included in the name -- we were passing an invalid combination of Unix > and VMS syntax to > vmsify, and getting a garbage result. Basically, for the following > two examples, we had to > prevent the second one from happening. > > 'file.dat' --> vmsifiy('./file.dat') > '[.foo]file.dat' --> vmsify('./[.foo]file.dat') # garbage in, garbage > out
I have folded this patch into my local repo, which is now in sync with blead. I added a test for rmtree($file). If you can confirm that the test does not blow up spectacularly on VMS, I'll release to CPAN. Thanks, David
MIME-Version: 1.0
X-Spam-Status: No, hits=-2.6 required=8.0 tests=BAYES_00
In-Reply-To: <rt-3.6.HEAD-27245-1195152195-546.30654-6-0 [...] rt.cpan.org>
References: <RT-Ticket-30654 [...] rt.cpan.org> <rt-3.6.HEAD-27245-1195152195-546.30654-6-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
X-RT-Original-Encoding: us-ascii
Received: from la.mx.develooper.com (x1.develooper.com [63.251.223.170]) by diesel.bestpractical.com (Postfix) with SMTP id 190F64D820D for <bug-File-Path [...] rt.cpan.org>; Thu, 15 Nov 2007 14:08:30 -0500 (EST)
Received: (qmail 19711 invoked by alias); 15 Nov 2007 19:08:30 -0000
Received: from smtpoutm.mac.com (HELO smtpoutm.mac.com) (17.148.16.78) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Thu, 15 Nov 2007 11:08:21 -0800
Received: from mac.com (asmtp002-s [10.150.69.65]) by smtpoutm.mac.com (Xserve/smtpout015/MantshX 4.0) with ESMTP id lAFJ7nvV020933 for <bug-File-Path [...] rt.cpan.org>; Thu, 15 Nov 2007 11:07:49 -0800 (PST)
Received: from [172.16.52.1] (dsl081-145-238.chi1.dsl.speakeasy.net [64.81.145.238]) (authenticated bits=0) by mac.com (Xserve/asmtp002/MantshX 4.0) with ESMTP id lAFJ7UOF018715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <bug-File-Path [...] rt.cpan.org>; Thu, 15 Nov 2007 11:07:32 -0800 (PST)
Delivered-To: cpan-bug+file-path [...] diesel.bestpractical.com
Subject: Re: [rt.cpan.org #30654] [PATCH] rmtree nit when handling file in VMS syntax
Return-Path: <craigberry [...] mac.com>
X-Spam-Check-BY: la.mx.develooper.com
X-Original-To: bug-File-Path [...] rt.cpan.org
Date: Thu, 15 Nov 2007 13:07:17 -0600
Message-Id: <p06240818c3624884c962 [...] [172.16.52.1]>
To: David Landgren via RT <bug-File-Path [...] rt.cpan.org>
From: "Craig A. Berry" <craigberry [...] mac.com>
X-RT-Original-Encoding: utf-8
RT-Message-ID: <rt-3.6.HEAD-27250-1195153721-1481.30654-0-0 [...] rt.cpan.org>
Content-Length: 1357
Download (untitled) / with headers
text/plain 1.3k
David, Everything File::Path related looked good in blead@32308, and your last update (including the new test) went in as 32305, so I'd say we're set. Thanks, Craig Show quoted text
><URL: http://rt.cpan.org/Ticket/Display.html?id=30654 > > >On Sun Nov 11 18:40:43 2007, CBERRY wrote:
>> Sorry to always be the bearer of ugly exceptions to exceptions, but >> I've checked the attached >> into blead as #32276 to get around the following problem. When an >> individual file already in >> VMS syntax was passed to rmtree -- and that file was a relative path >> with at least one directory >> included in the name -- we were passing an invalid combination of Unix >> and VMS syntax to >> vmsify, and getting a garbage result. Basically, for the following >> two examples, we had to >> prevent the second one from happening. >> >> 'file.dat' --> vmsifiy('./file.dat') >> '[.foo]file.dat' --> vmsify('./[.foo]file.dat') # garbage in, garbage >> out
> >I have folded this patch into my local repo, which is now in sync with >blead. I added a test for rmtree($file). If you can confirm that the >test does not blow up spectacularly on VMS, I'll release to CPAN. > >Thanks, >David
-- Show quoted text
________________________________________ Craig A. Berry mailto:craigberry@mac.com "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
MIME-Version: 1.0
X-Mailer: MIME-tools 5.418 (Entity 5.418)
Content-Disposition: inline
Charset: utf8
Message-Id: <rt-3.6.HEAD-2012-1199656189-1375.30654-0-0 [...] rt.cpan.org>
Content-Type: text/plain
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Original-Encoding: utf-8
Content-Length: 196
Download (untitled) / with headers
text/plain 196b
This fix appears in 2.04. Sorry for the late reply, search.cpan.org took a long time to refresh its metadata so that I could add the version in which the module was fixed. Regards, David Landgren


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.