Bug #39949 for File-Path: in cygwin and windows rmtree does not report any error if directory does not exist

Fri Oct 10 09:54:09 2008 dmitry.bolshakov [...] bridge-quest.com - Ticket created

Subject:	in cygwin and windows rmtree does not report any error if directory does not exist
Date:	Fri, 10 Oct 2008 17:53:20 +0400
To:	bug-File-Path [...] rt.cpan.org
From:	Dmitry Bolshakov <dmitry.bolshakov [...] bridge-quest.com>

$ uname -a CYGWIN_NT-5.1 bolshakovxp 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin $ perl -v This is perl, v5.10.0 built for cygwin-thread-multi-64int (with 6 registered patches, see perl -V for more detail) $ perl -MFile::Path -e "print \$File::Path::VERSION" 2.04 ----- Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\Documents and Settings\bdimych>perl -v This is perl, v5.10.0 built for MSWin32-x86-multi-thread (with 5 registered patches, see perl -V for more detail) C:\Documents and Settings\bdimych>perl -MFile::Path -e "print $File::Path::VERSION" 2.04 ----- use File::Path; use Data::Dumper; rmtree "aaaaa", {error => \my $err}; print Dumper $err; <STDIN>; outputs $VAR1 = []; -- With best regards Dmitry Bolshakov

Sat May 02 10:11:15 2015 RICHE [...] cpan.org - Correspondence added 10 min

Created PR https://github.com/dland/File-Path/pull/5 On Fri Oct 10 09:54:09 2008, dmitry.bolshakov@bridge-quest.com wrote: Show quoted text

> $ uname -a > CYGWIN_NT-5.1 bolshakovxp 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin > > $ perl -v > This is perl, v5.10.0 built for cygwin-thread-multi-64int > (with 6 registered patches, see perl -V for more detail) > > $ perl -MFile::Path -e "print \$File::Path::VERSION" > 2.04 > > ----- > > Microsoft Windows XP [Version 5.1.2600] > (C) Copyright 1985-2001 Microsoft Corp. > > C:\Documents and Settings\bdimych>perl -v > > This is perl, v5.10.0 built for MSWin32-x86-multi-thread > (with 5 registered patches, see perl -V for more detail) > > C:\Documents and Settings\bdimych>perl -MFile::Path -e "print > $File::Path::VERSION" > 2.04 > > ----- > > use File::Path; > use Data::Dumper; > rmtree "aaaaa", {error => \my $err}; > print Dumper $err; > <STDIN>; > > outputs > > $VAR1 = []; > >

Sat May 02 10:11:15 2015 The RT System itself - Status changed from 'new' to 'open'

Fri Jun 26 11:49:11 2015 RICHE [...] cpan.org - Correspondence added

This issue has been resolved in dev release http://search.cpan.org/~riche/File-Path/Path.pm version 2.10_001.

Fri Jun 26 11:49:17 2015 RICHE [...] cpan.org - Status changed from 'open' to 'resolved'

Fri Jun 26 11:49:18 2015 RICHE [...] cpan.org - Taken

Fri Jun 26 11:49:18 2015 RICHE [...] cpan.org - Fixed in 2.10_001 added

Mon Jul 27 18:30:49 2015 rjbs [...] cpan.org - Correspondence added

I have read through this full thread a few times, and I find myself feeling pretty firmly opposed to this change. There is already a mechanism for determining whether any of the requested deletions failed, and it has been there for some time. (I am thinking, here, of the return value and the error reference.) Users already could have inspected if if they cared to, and if they did not, that is their choice, even if we would not make it the same way. If we were to change perl's core "mkdir" to warn on failure, rather than stick to its existing behavior, users would scream bloody murder. That's not the kind of change that the perl core makes lightly. File::Path is so important a piece of core — and indeed was fundamentally core-only until v5.10 — that I think it should try to stick to the same level of backward compatibility. But it may well be that I haven't quite grasped the motivation here. It sounds like, "users might be surprised that nothing got deleted, or why nothing got deleted," but the tools for checking this already exist, and are already documented. They're maybe not the interface we'd provide if we were starting afresh, but we're not. We're supporting decades of code with coders and maintainers who will (justifiably) scream bloody murder if we change their programs to emit warnings where they already understand the behavior. If I have misunderstood, and there is a greater issue at play, please let me know. Otherwise, the complaints here are just the tip of an iceberg, and we should avoid it by avoiding these new warnings. -- rjbs

Mon Jul 27 18:30:57 2015 rjbs [...] cpan.org - Status changed from 'resolved' to 'open'

Mon Jul 27 18:36:37 2015 rjbs [...] cpan.org - Correspondence added

Whoops, I have responded to the wrong ticket. :-) -- rjbs

Mon Jul 27 18:43:02 2015 ether [...] cpan.org - Correspondence added

re-closing.

Mon Jul 27 18:43:12 2015 ether [...] cpan.org - Status changed from 'open' to 'resolved'

Thu Aug 06 19:08:02 2015 jkeenan [...] cpan.org - Reference by ticket #105935 added