Front page | perl.perl5.porters |
Postings from May 2008
Re: File::Path::mkpath() incompatiblity in perl-5.10
Thread Previous
|
Thread Next
From:
David Landgren
Date:
May 15, 2008 07:31
Subject:
Re: File::Path::mkpath() incompatiblity in perl-5.10
Message ID:
482C493F.1030102@landgren.net
Gisle Aas wrote:
> On May 14, 2008, at 23:53, David Landgren wrote:
>
>>
>> Hmm. Sorry about that. I'm working on a more robust approach that will
>> put an end to all this.
>
> Could you at least indicate what this more robust approach would be?
It's quite simple, basically, don't try to infer anything about the
second param, just its presence.
The old style is triggered by any of
- one parameter passed
- two parameters passed and second is numeric
- three parameters passed; second and third parameters are numeric
The mistake was to see if the second param was numeric (as per your
"verbose" argument). So the new way is merely:
- one parameter passed
- two parameters passed
- three parameters passed and third parameters is numeric
> I really want an mkpath() function in 5.10 that's 100% compatible with
> the interface documented in 5.8. The only way I can see that happening
So do I; I thought I had done so. Despite your misgivings, I still think
it is possible.
> is if you require a hash ref as the last argument to trigger the new
> interface,
If the routine is called with four or more params, it must be the new
style, because the old style only looked at three params at the most.
No promises were made either way regarding the handling of arguments
beyond those documented, if mkdir('foo', 1, 0755, 'bar') now creates
four directories instead of one, it's because of a latent bug in the
original client code, since the programmer did not read the
documentation correctly.
I don't think we need to bend over quite so far in order to maintain
backwards compatibility, only for code that respected the API.
> or that you simply move the new interface to a new function
> name and leave the old interface alone. Using the name make_path() for
> the "modern" interface seems like an improvement in readability as well,
> and would be my preferred approach.
I wish I had received this feedback a year ago. There might be code out
there now that relies on the new style mkpath(), so it can't be stripped
out now.
There are two other issues I am addressing, the fact that (stat $foo)[1]
(the inode) always returns 0 on Windows (and thus prevents UNC paths
from being removed), and asking to remove the current directory (or
ancestor), for which the code now croaks when it tries to chdir back to
the original directory at the end of the run, and it's been blown away.
The solution to the first can be solved if Win32::IdentifyFile is available.
The second is a hassle. Suppose one is in /path/to/some/dir.
Given
rmtree( '../../to', 'here/too', {verbose=>0} );
(I keep writing 'rmpath', maybe that needs to be aliased as well...)
we are first asked to remove /path/to. When the code finishes, the cwd
is /path. We then try to chdir back to /path/to/some/dir, but this is
one of those cases where we simply cannot restore things to the initial
state. Thus the cwd is irrevocably changed.
Normally this occurs in tear-down situations, when we're cleaning up
just before the end of the program, so if the cwd was left hanging in
limbo (as in the 1.x version) no-one ever noticed.
All this changed when the race prevention code was added, which requires
manipulating the cwd.
Right now, the code croaks in this situation. If we don't croak, then in
the above snippet, we would begin to remove /path/here/too, which would
definitely not be a good idea. (It was /path/to/some/dir/here/too that
was queued for removal).
So I'm thinking that the right things to do is to not croak and just
ignore the remaining directories in the list to be unlinked, and the
current directory remains changed. (I find the idea of attempting to
renormalise relative and absolute directories from one point to another
in the file system fraught with peril, even if there are modules that do
this sort of thing. I don't want to be responsible for someone unlinking
the root directory).
David
Thread Previous
|
Thread Next