develooper Front page | perl.perl5.porters | Postings from May 2008

Re: File::Path::mkpath() incompatiblity in perl-5.10

Thread Previous | Thread Next
David Landgren
May 15, 2008 07:31
Re: File::Path::mkpath() incompatiblity in perl-5.10
Message ID:
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.


   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).


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About