# from Adam Kennedy
# on Wednesday 14 January 2009 17:00:
>Indefinite retry is not a good idea, but limited retry should cover
>almost every case that is laggy without preventing legitimate failures
>from happening.
Of course not and yes, Certainly.
do {unlink($file) and last; -e $file and die
On Wed, Jan 14, 2009 at 8:12 PM, Eric Wilhelm wrote:
> David, would you like to look into whether a function/method like this
> would make sense as part of the M::B::Win32 API or possibly just a bit
> of the testing support code.
>
I think it could just be in the tests. I don't think it's a "bug
On Wed, Jan 14, 2009 at 7:12 PM, Eric Wilhelm
wrote:
> # from Adam Kennedy
> # on Wednesday 14 January 2009 17:00:
>
>>Indefinite retry is not a good idea, but limited retry should cover
>>almost every case that is laggy without preventing legitimate failures
>>from happening.
>
> Of course not an
On Thu, 15 Jan 2009, Ken Williams wrote:
> On Wed, Jan 14, 2009 at 7:12 PM, Eric Wilhelm
> > do {unlink($file) and last; -e $file and die $!;
> > warn "cannot unlink $file\n"; sleep 1; } for(1..20);
>
> I'm not sure what we're talking about. Is it "1 while unlink $f"?
>
> If so, see this text
On Thu, Jan 15, 2009 at 9:05 PM, Ken Williams wrote:
> I'm not sure what we're talking about. Is it "1 while unlink $f"?
>
No.
There are a couple places that use rmtree to delete stuff. Base.pm and also
some of the t/lib files.
I've found that if I load my windows machine enough, I can cause
On Thu, 15 Jan 2009, David Golden wrote:
> I've found that if I load my windows machine enough, I can cause rmtree to
> fail due to permissions -- usually because a file couldn't be deleted. Best
> hypothesis is that it's due a virus scanner that is too slow due to the
> loading to check the file
# from Jan Dubois
# on Thursday 15 January 2009 18:58:
>On Thu, 15 Jan 2009, David Golden wrote:
>>Sadly, even my proposed "for (1 .. 20) " type loop around rmtree were
>>insufficient to avoid the problem.
>You could create an additional single temp directory, redefine
>CORE::GLOBAL::unlink() to
On Thu, Jan 15, 2009 at 10:52 PM, Eric Wilhelm
wrote:
> David, is it indeed only an issue with compat.t?
>
No, though compat.t seems to provoke it more reliably. I've seen it
triggered from other .t files.
I think a less draconian solution is to provide a "is_removed()" test
function that tests
Personally, I don't mind at all.
All Strawberry installs since the October release support
configure_requires out of the box and are configured to always prefer
Build.PL (pretty sure on that last one, but I'll double check it for
the January release).
Adam K
2009/1/16 Eric Wilhelm :
> So, I'm in
On Fri, 16 Jan 2009 19:25:55 +1100, "Adam Kennedy"
said:
> Personally, I don't mind at all.
>
> All Strawberry installs since the October release support
> configure_requires out of the box and are configured to always prefer
> Build.PL (pretty sure on that last one, but I'll double check it for
10 matches
Mail list logo
