File::Find:name set to empty string for "/" #4647

p5pRT · 2001-12-06T15:10:55Z

Migrated from rt.perl.org#7998 (status was 'resolved')

Searchable as RT7998$

p5pRT · 2001-12-06T15:10:55Z

From @jimav

This is a bug report for perl from james_avera@yahoo.com,
generated with the help of perlbug 1.33 running under perl v5.6.1.

#!/usr/bin/perl -w
#
# File::Find::finddepth() sets $File::Find::name to the empty string
# for the starting directory if that directory is "/".
#
# Run this program to demo the bug.
#
# -Jim Avera (james_avera@yahoo.com) 12/3/01
#
use strict;
use File::Find;
$ENV{PATH}="/bin:/usr/bin";
select STDERR; $|=1; select STDOUT; $|=1;

die "must be root" unless ($> == 0);

# The following block sets up a small chroot test directory and runs
# in that, so the test runs fast. If you don't want to do taht, then comment
# out this block and the test will run on the real file system.
{ my $tmproot = "/tmp/bug.root.d";
my @libs = (`ldd /bin/pwd` =~ /^.*=>\s+(\S+)/gm);
( $? == 0
&& system("rm","-rf", $tmproot)==0
&& mkdir($tmproot)
&& system("cp", "-a", "--dereference", "--parents",
"/bin/pwd", @libs, $tmproot)==0
&& mkdir("$tmproot/A")
) || die "Could not set up $tmproot";
chroot $tmproot || die $!;
chdir "/";
}

# Here is the test itself
finddepth sub {
foreach my $ident (qw(_ File::Find::dir File::Find::name)) {
no strict 'refs';
if (length($$ident) == 0) {
my @s = lstat $_;
die "BUG FOUND in finddepth() \$$ident is the empty string\n"
."_='$_' name='$File::Find::name' dir='$File::Find::dir'"
." dev=$s[0], ino=$s[1]\n";
}
}
}, "/"; # bug occurs only for "/", not other dirs

Flags:
category=library
severity=critical

Site configuration information for perl v5.6.1:

Configured by root at Thu Sep 20 02:27:59 GMT 2001.

Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
Platform:
osname=linux, osvers=2.4.9, archname=i586-linux
uname='linux reiser 2.4.9 #1 smp wed sep 19 12:11:44 gmt 2001 i686 unknown '
config_args='-ds -e -Dprefix=/usr -Di_db -Di_dbm -Di_ndbm -Di_gdbm'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
Compiler:
cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O2 -pipe',
cppflags='-fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='2.95.3 20010315 (SuSE)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, usemymalloc=n, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -ldl -lm -lc -lcrypt -lutil
perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil
libc=, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:

@INC for perl v5.6.1:
/usr/lib/perl5/5.6.1/i586-linux
/usr/lib/perl5/5.6.1
/usr/lib/perl5/site_perl/5.6.1/i586-linux
/usr/lib/perl5/site_perl/5.6.1
/usr/lib/perl5/site_perl
.

Environment for perl v5.6.1:
HOME=/home/jima
LANG=en_US
LANGUAGE (unset)
LC_COLLATE=POSIX
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=/home/jima/bin:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/lib/java/bin:/var/lib/dosemu:/usr/games/bin:/usr/games:/opt/bin:/opt/gnome/bin:/opt/kde2/bin:/opt/kde/bin:/usr/openwin/bin:.:/opt/pilotsdk/bin:/opt/jima/bin:/usr/sbin:/sbin
PERL_BADLANG (unset)
SHELL=/bin/bash

p5pRT · 2001-12-09T05:53:56Z

From [Unknown Contact. See original ticket]

james_avera@yahoo.com wrote:

File::Find::finddepth() sets $File::Find::name to the empty string
for the starting directory if that directory is "/".

This is a patch fixing the bug reported as [ID 20011206.007] against
the version found at the activestate repository
file://depot/perl/lib/File/Find.pm#38 - edit change 10383 (text)

The same patch can be applied to the 5.6.0 version.

All tests in filefind.t v5.6.0 still show ok.

Regards,
-Wolfgang Laun

*** lib/File/Find.pm.orig Sun Dec 9 11:26:20 2001
--- lib/File/Find.pm Sun Dec 9 12:41:19 2001
***************
*** 551,554 ****
--- 550,555 ----
if ( substr($name,-2) eq '/.' ) {
$name =~ s|/\.$||;
+ # avoid empty name after return to '/'
+ $name = '/' unless length( $name );
}
$dir = $p_dir;

p5pRT · 2001-12-09T11:31:50Z

From @gsar

On Sun, 09 Dec 2001 13:45:06 +0100, "Wolfgang Laun" wrote:

james_avera@yahoo.com wrote:

File::Find::finddepth() sets $File::Find::name to the empty string
for the starting directory if that directory is "/".

This is a patch fixing the bug reported as [ID 20011206.007] against
the version found at the activestate repository
file://depot/perl/lib/File/Find.pm#38 - edit change 10383 (text)

The same patch can be applied to the 5.6.0 version.

All tests in filefind.t v5.6.0 still show ok.

Regards,
-Wolfgang Laun

*** lib/File/Find.pm.orig Sun Dec 9 11:26:20 2001
--- lib/File/Find.pm Sun Dec 9 12:41:19 2001
***************
*** 551,554 ****
--- 550,555 ----
if ( substr($name,-2) eq '/.' ) {
$name =~ s|/\.$||;
+ # avoid empty name after return to '/'
+ $name = '/' unless length( $name );
}
$dir = $p_dir;

There appear to be three other similar places that will be hit when
the follow and no_chdir options are used (grep for /substr.*-2/ to
find them). Can you confirm and patch those other spots as well if
they need patching?

Thanks.

Sarathy
gsar@ActiveState.com

p5pRT · 2001-12-09T14:51:58Z

From [Unknown Contact. See original ticket]

-----BEGIN PGP SIGNED MESSAGE-----

Moin,

Gurusamy Sarathy <gsar@ActiveState.com> wrote.

On Sun, 09 Dec 2001 13:45:06 +0100, "Wolfgang Laun" wrote:

james_avera@yahoo.com wrote:

File::Find::finddepth() sets $File::Find::name to the empty string
for the starting directory if that directory is "/".

This is a patch fixing the bug reported as [ID 20011206.007] against
the version found at the activestate repository
file://depot/perl/lib/File/Find.pm#38 - edit change 10383 (text)

The same patch can be applied to the 5.6.0 version.

All tests in filefind.t v5.6.0 still show ok.

Regards,
-Wolfgang Laun

*** lib/File/Find.pm.orig Sun Dec 9 11:26:20 2001
--- lib/File/Find.pm Sun Dec 9 12:41:19 2001
***************
*** 551,554 ****
--- 550,555 ----
if ( substr($name,-2) eq '/.' ) {
$name =~ s|/\.$||;
+ # avoid empty name after return to '/'
+ $name = '/' unless length( $name );
}
$dir = $p_dir;

There appear to be three other similar places that will be hit when
the follow and no_chdir options are used (grep for /substr.*-2/ to
find them). Can you confirm and patch those other spots as well if
they need patching?

Wouldn't it be better to write that as:

$name =~ s/(.)\/\.$/$1/; # remove trailing slash

Certainly shorter and should do the same (I hope ;)

Btw, I think File::Spec could also be used - not anyone has '/' as a root
dir.

Cheers,

Tels

- --
perl -MMath::String -e 'print \
Math::String->from_number("215960156869840440586892398248"),"\n"'

http://bloodgate.com/perl My current Perl projects
PGP key available on http://bloodgate.com/tels.asc or via email.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: latin1

iQEVAwUBPBPjSncLPEOTuEwVAQFKhgf+IXFqCFGvHAJoOQQ52Pog2wy9uNWTWwnN
KepqXF8J/v7rIAaPpIcOqlPF4YbdoXdu1r2Bu72VPazcwd5dtcc7DJUAxr7KMY+s
r1gx32VDnw0kfE/eOf8/Vn9Caz5/rIr+euxEuQkSA7f/cB+JHDfjwD4fmSyCoWK+
q7bCangOSlgLkCl0Vb+Tl8nRn/eIfvr5sM+JqCKtQ+5XJWhgwOMmM1NVPyUoX5I7
wYgb6jB6gkA8+A2GaV5+fTplRL5+CyEkGTs7NXDMs7/j6JVhRZ5wti/pl32wGP99
Pdd7Ad00RggbS1VYstDR6wRE+HjO+gEQeCAhe1sJZTAWPPAikO3RbQ==
=t4j/
-----END PGP SIGNATURE-----

p5pRT · 2001-12-11T01:25:21Z

From [Unknown Contact. See original ticket]

Tels <perl_dummy@bloodgate.com> wrote:

On Sun, 09 Dec 2001 13:45:06 +0100, "Wolfgang Laun" wrote:

james_avera@yahoo.com wrote:

File::Find::finddepth() sets $File::Find::name to the empty string
for the starting directory if that directory is "/".

This is a patch fixing the bug reported as [ID 20011206.007]

[ ...possibly required in other places as well... ]

*** lib/File/Find.pm.orig Sun Dec 9 11:26:20 2001
--- lib/File/Find.pm Sun Dec 9 12:41:19 2001
***************
*** 551,554 ****
--- 550,555 ----
if ( substr($name,-2) eq '/.' ) {
$name =~ s|/\.$||;
+ # avoid empty name after return to '/'
+ $name = '/' unless length( $name );
}
$dir = $p_dir;

Wouldn't it be better to write that as:
   $name =~ s/$\.$\\/\\\.$/$1/;        \# remove trailing slash
Certainly shorter and should do the same (I hope ;)

It still misses the case where '/.' needs to become '/'. You can
do it with a single s/// (see below), but neither is the fastest
solution. Some benchmarking, combining $name values with existing
and proposed solutions:

hit_1 ... /foo/bar/blech/. => /foo/bar/blech
hit_2 ... /. => /
miss ... /foo/bar/blech no change

Find ... code as in the above patch
nopat:
if ( substr($name,-2) eq '/.' ) {
substr($name,length($name)==2 ? -1 : -2) = '';
}
pat1:
$name =~ s{((?<=.)/|(?<=/))\.$}{};
tels:
if( $name !~ s/(.)\/\.$/$1/ ){
$name = '/' if $name eq '/.';
}

Benchmark: timing 500000 iterations of Find_hit_1, Find_hit_2,
Find_miss, nopat_hit_1, nopat_hit_2, nopat_miss, pat1_hit_1, pat1_hit_2,
pat1_miss, tels_hit_1, tels_hit_2, tels_miss...
Find_hit_1: 5 wallclock secs ( 6.06 usr + 0.00 sys = 6.06 CPU) @
82508.25/s (n=500000)
Find_hit_2: 8 wallclock secs ( 6.97 usr + 0.00 sys = 6.97 CPU) @
71736.01/s (n=500000)
Find_miss: 2 wallclock secs ( 1.48 usr + 0.01 sys = 1.49 CPU) @
335570.47/s (n=500000)
nopat_hit_1: 5 wallclock secs ( 5.56 usr + 0.00 sys = 5.56 CPU) @
89928.06/s (n=500000)
nopat_hit_2: 5 wallclock secs ( 5.59 usr + 0.00 sys = 5.59 CPU) @
89445.44/s (n=500000)
nopat_miss: 1 wallclock secs ( 1.48 usr + 0.00 sys = 1.48 CPU) @
337837.84/s (n=500000)
pat1_hit_1: 10 wallclock secs ( 8.99 usr + 0.00 sys = 8.99 CPU) @
55617.35/s (n=500000)
pat1_hit_2: 8 wallclock secs ( 7.71 usr + 0.00 sys = 7.71 CPU) @
64850.84/s (n=500000)
pat1_miss: 2 wallclock secs ( 1.39 usr + 0.00 sys = 1.39 CPU) @
359712.23/s (n=500000)
tels_hit_1: 15 wallclock secs (15.16 usr + -0.01 sys = 15.15 CPU) @
33003.30/s (n=500000)
tels_hit_2: 3 wallclock secs ( 1.69 usr + -0.01 sys = 1.68 CPU) @
297619.05/s (n=500000)
tels_miss: 3 wallclock secs ( 1.63 usr + 0.01 sys = 1.64 CPU) @
304878.05/s (n=500000)

Since hit_1 and miss are the frequent cases, root dirs being indeed
rare,
the ranking is nopat < Find < ...

Btw, I think File::Spec could also be used - not anyone has '/' as a root
dir.

Gaining what? It'd require an extensive rewrite of File::Find, and most
likely slow it down.

Regards,
-Wolfgang Laun

p5pRT · 2001-12-11T09:30:54Z

From [Unknown Contact. See original ticket]

-----BEGIN PGP SIGNED MESSAGE-----

Moin,

On 11-Dec-01 Wolfgang Laun tried to scribble about:

Wouldn't it be better to write that as:
   $name =~ s/$\.$\\/\\\.$/$1/;        \# remove trailing slash
Certainly shorter and should do the same (I hope ;)
It still misses the case where '/.' needs to become '/'. You can
do it with a single s/// (see below), but neither is the fastest
solution. Some benchmarking, combining $name values with existing
and proposed solutions:

I shouldn't post without two cups of coffee and actually trying what I
propose. Forget the entire proposal.

Btw, I think File::Spec could also be used - not anyone has '/' as a root
dir.

Gaining what?

That File::Find work's on more platforms (possible)?

It'd require an extensive rewrite of File::Find,

That is the biggest argument against it ;)

and most likely slow it down.

Some people prefer slow, working programs that return the correct result to
fast, broken solutions ;)

But Murphy says never touch running things... ;)

Cheers,

Tels

- --
perl -MDev::Bollocks -e'print Dev::Bollocks->rand(),"\n"'
greatly initiate collaborative data

http://bloodgate.com/perl My current Perl projects
PGP key available on http://bloodgate.com/tels.asc or via email

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: latin1

iQEVAwUBPBZB63cLPEOTuEwVAQHVnQf/RA4tSuVmST5MrEFuVQUEzKs4FfRViMbQ
txciOJPE5zd5JrXfLX2RXYTYyvaKrbF9zPRO55b5T8gVamIAB/NhF0SSOgTWOQaS
y1medWBmwxxXmuv0mdJrKrqrX/XsPwxQ15H+vQo/IHbtbDh5tAHB6kaoLdmM/KW/
ArtGyWNUdFIAFhXBXEZUDxydokJ+d86dyBnZdwr4MnmIk4Z8p3OdxVYg5QoDia/o
svZR9piGyTXTFoUIss3pXwkXyhYlu7xcscdDV1aYQvoFo7cxu18Of9tDSaicnA//
tTl0bY6tEGMVCKaMPo27m6sFkM+i/6dnnnZSTJFQsMK+Zo/DX49vbw==
=JWt3
-----END PGP SIGNATURE-----

p5pRT · 2001-12-11T10:40:23Z

From [Unknown Contact. See original ticket]

On 09.12.01 at 11:31 Gurusamy Sarathy wrote:

There appear to be three other similar places that will be hit when
the follow and no_chdir options are used (grep for /substr.*-2/ to
find them). Can you confirm and patch those other spots as well if
they need patching?

What we should learn from Ents: not to be too hasty ;-)

There's indeed one other place where $File::Find::name is
reduced to the null string. Other occurrences of s|/\.$||
clean up relative path names.

Regards,
-Wolfgang Laun

*** lib/File/Find.pm.orig Tue Dec 11 18:04:44 2001
--- lib/File/Find.pm Tue Dec 11 17:54:07 2001
***************
*** 550,553 ****
--- 550,555 ----
if ( substr($name,-2) eq '/.' ) {
$name =~ s|/\.$||;
+ # avoid empty name after return to '/'
+ $name = '/' unless length( $name );
}
$dir = $p_dir;
***************
*** 706,709 ****
--- 708,713 ----
if ( substr($name,-2) eq '/.' ) {
$name =~ s|/\.$||;
+ # avoid empty name after return to '/'
+ $name = '/' unless length( $name );
}
$dir = $p_dir;

p5pRT · 2001-12-11T13:19:16Z

From [Unknown Contact. See original ticket]

On Tue, 11 Dec 2001 02:24:03 -0700, Wolfgang Laun wrote:

Btw, I think File::Spec could also be used - not anyone has '/' as a root
dir.

Gaining what? It'd require an extensive rewrite of File::Find, and most likely
slow it down.

For what it's worth, I started on that a couple of months ago, and got bogged
down testing anywhere but Unix. The code's approximately 50% shorter and is
almost ready to get a nicer interface, based on requests from Nat and MJD.

http://wgz.org/chromatic/perl/File-Find.tar.gz

-- c

p5pRT · 2001-12-12T03:22:19Z

From [Unknown Contact. See original ticket]

Gurusamy Sarathy <gsar@ActiveState.com> wrote:

Just to be sure, won't the two occurrences of:

$_ = ($no_chdir ? $dir_name : $dir_rel);
if ( substr($_,-2) eq '/.' ) {
s|/\.$||;
}

result in $_ becoming "" when $dir_name is "/."?

It may indeed be safer to have $_ never be equal to "" since
'/' . '.' (or even '/'.'/'.'.') is still *logically* equal to '/'
whereas trying to use a relative path "" is bound to cause trouble
in the users wanted().

Doesn't that
invalidate the documentation which says:

"no_chdir"
Does not "chdir()" to each directory as it recurses. The wanted()
function will need to be aware of this, of course. In this case, "$_"
will be the same as "$File::Find::name".

? It could well be that the documentation needs the "/" special case
mentioned more copiously.

I hope to have clarified this with an insert into the pod section.
(Should readers explicitly be made aware of F<//.> is-same-as F<//>
is-same-as F</> ?)

Also, should $_ too be non-zero length always irrespective of whether
the no_chdir option is being used? (i.e. may need special casing
for "/".)

Basically it seems to me that all of the $File::File::* variables
that point to files or directories (whether absolute or relative)
need to be valid (non-empty) always. So under the boundary
condition where $File::Find::name eq "/", all of these variables
need to be "/" also. I have no idea if doing this might break any
code out there though--we should pick some sort of reasonable
implementation that maintains this useful invariant (enabled via
an option if breakage might be an issue).

I've patched all occurences of the /. substitution (just to be on
the safe side; I didn't try to assert that all are *required*;
and moreover it's faster than the pattern match anyway). See the pod
insert below for what is actually returned. I've run all 4 cases:
find + finddepth( {...}, '/'), no_chdir=>0 and =>1, with these
assertions in wanted():

if( $no_chdir ){
die( "no_chdir: \$_=$_, \$File::Find::name=$File::Find::name\n" )
unless $_ eq $File::Find::name;
my( $name, $path ) = fileparse( $File::Find::name );
unless( $path eq $File::Find::dir . '/'
||
$path eq '/' && $path eq $File::Find::dir ){
die( "no_chdir: \$path=$path, \$File::Find::dir=$File::Find::dir\n" );
}
} else {
unless( "$File::Find::dir/$_" eq $File::Find::name
||
$File::Find::dir eq '/' &&
( ( "$File::Find::dir" eq $File::Find::name && $_ eq '.' )
|| "$File::Find::dir$_" eq $File::Find::name )
){
die( "chdir: \$File::Find::dir=$File::Find::dir, \$_=$_, \$File::Find::name=$File::Find::name\n" );
}
}

Thanks for the prodding ;-)
-Wolfgang

*** lib/File/Find.pm.orig Tue Dec 11 18:04:44 2001
--- lib/File/Find.pm Wed Dec 12 09:45:46 2001
***************
*** 137,141 ****
the complete pathname to the file. You are chdir()'d to
C<$File::Find::dir> when the function is called, unless C<no_chdir>
! was specified. When <follow> or <follow_fast> are in effect, there is
also a C<$File::Find::fullname>. The function may set
C<$File::Find::prune> to prune the tree unless C<bydepth> was
--- 137,156 ----
the complete pathname to the file. You are chdir()'d to
C<$File::Find::dir> when the function is called, unless C<no_chdir>
! was specified. Note that when changing to directories is in effect
! the root directory (F</>) is a somewhat special case inasmuch as the
! concatenation of C<$File::Find::dir>, C<'/'> and C<$_> is not literally
! equal to C<$File::Find::name>. The table below summarizes all variants:
!
! $File::Find::name $File::Find::dir $_
! default / / .
! no_chdir=>0 /etc / etc
! /etc/x /etc x
!
! no_chdir=>1 / / /
! /etc / /etc
! /etc/x /etc /etc/x
!
!
! When <follow> or <follow_fast> are in effect, there is
also a C<$File::Find::fullname>. The function may set
C<$File::Find::prune> to prune the tree unless C<bydepth> was
***************
*** 549,558 ****
$name = $dir_name;
if ( substr($name,-2) eq '/.' ) {
! $name =~ s|/\.$||;
}
$dir = $p_dir;
$_ = ($no_chdir ? $dir_name : $dir_rel );
if ( substr($_,-2) eq '/.' ) {
! s|/\.$||;
}
{ &$wanted_callback }; # protect against wild "next"
--- 564,573 ----
$name = $dir_name;
if ( substr($name,-2) eq '/.' ) {
! substr($name, length($name) == 2 ? -1 : -2) = '';
}
$dir = $p_dir;
$_ = ($no_chdir ? $dir_name : $dir_rel );
if ( substr($_,-2) eq '/.' ) {
! substr($_, length($_) == 2 ? -1 : -2) = '';
}
{ &$wanted_callback }; # protect against wild "next"
***************
*** 705,714 ****
$name = $dir_name;
if ( substr($name,-2) eq '/.' ) {
! $name =~ s|/\.$||;
}
$dir = $p_dir;
$_ = ($no_chdir ? $dir_name : $dir_rel);
if ( substr($_,-2) eq '/.' ) {
! s|/\.$||;
}

--- 720,729 ----
$name = $dir_name;
if ( substr($name,-2) eq '/.' ) {
! substr($name,length($name) == 2 ? -1 : -2) = '';
}
$dir = $p_dir;
$_ = ($no_chdir ? $dir_name : $dir_rel);
if ( substr($_,-2) eq '/.' ) {
! substr($_,length($_) == 2 ? -1 : -2) = '';
}

p5pRT · 2003-07-16T06:39:44Z

From @schwern

Has this been fixed? Can we resolve this bug?

p5pRT · 2005-06-10T00:42:34Z

From @smpeters

[schwern - Tue Jul 15 23:39:44 2003]:

Has this been fixed? Can we resolve this bug?

Yes we can. This was applied with change #13654.

p5pRT · 2005-06-10T00:42:36Z

@smpeters - Status changed from 'open' to 'resolved'

p5pRT closed this as completed Jun 10, 2005

p5pRT added affects-5.6 distro-Linux type-library labels Oct 18, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

File::Find:name set to empty string for "/" #4647

File::Find:name set to empty string for "/" #4647

p5pRT commented Dec 6, 2001

p5pRT commented Dec 6, 2001

p5pRT commented Dec 9, 2001

p5pRT commented Dec 9, 2001

p5pRT commented Dec 9, 2001

p5pRT commented Dec 11, 2001

p5pRT commented Dec 11, 2001

p5pRT commented Dec 11, 2001

p5pRT commented Dec 11, 2001

p5pRT commented Dec 12, 2001

p5pRT commented Jul 16, 2003

p5pRT commented Jun 10, 2005

p5pRT commented Jun 10, 2005

File::Find:name set to empty string for "/" #4647

File::Find:name set to empty string for "/" #4647

Comments

p5pRT commented Dec 6, 2001

p5pRT commented Dec 6, 2001

From @jimav

p5pRT commented Dec 9, 2001

From [Unknown Contact. See original ticket]

p5pRT commented Dec 9, 2001

From @gsar

p5pRT commented Dec 9, 2001

From [Unknown Contact. See original ticket]

p5pRT commented Dec 11, 2001

From [Unknown Contact. See original ticket]

p5pRT commented Dec 11, 2001

From [Unknown Contact. See original ticket]

p5pRT commented Dec 11, 2001

From [Unknown Contact. See original ticket]

p5pRT commented Dec 11, 2001

From [Unknown Contact. See original ticket]

p5pRT commented Dec 12, 2001

From [Unknown Contact. See original ticket]

p5pRT commented Jul 16, 2003

From @schwern

p5pRT commented Jun 10, 2005

From @smpeters

p5pRT commented Jun 10, 2005