# from David Golden
# on Wednesday 14 January 2009 04:49:
>Without really understanding the details,
>my wild guess is that calling "unlink" schedules a file for deletion
> and there is a lag before it executes and subsequent checks for
> deletion sometimes fail. I've been able to make the proble
Based on the thread about my file deletion heisenbug and the likelihood that
a virus scanner was keeping files open preventing deletion, I propose the
following patch specific to Windows. It's cut-and-paste from Base.pm, but
adding a loop around rmtree.
I'd appreciate any feedback you might have
2009/1/15 Adam Kennedy :
> Looks fine, although personally I'd...
>
> sleep $i;
>
> ... and maybe ...
>
> $self->log_info("Couldn't remove '$_'; trying " . (5 - $i) . " more times\n");
>
> Adam K
>
> 2009/1/15 David Golden :
>> Based on the thread about my file deletion heisenbug and the likelihood
Looks fine, although personally I'd...
sleep $i;
... and maybe ...
$self->log_info("Couldn't remove '$_'; trying " . (5 - $i) . " more times\n");
Adam K
2009/1/15 David Golden :
> Based on the thread about my file deletion heisenbug and the likelihood that
> a virus scanner was keeping files o
# from demerphq
# on Thursday 15 January 2009 03:39:
>If this is meant to deal with installation issues then perhaps it
>should use the "schedule file for deletion at reboot" API, similar to
>how ExtUtils::Install deals with DLL's that are in use by the
>installation/build process.
I think it is
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
2009/1/16 Eric Wilhelm :
> # from demerphq
> # on Thursday 15 January 2009 03:39:
>
>>If this is meant to deal with installation issues then perhaps it
>>should use the "schedule file for deletion at reboot" API, similar to
>>how ExtUtils::Install deals with DLL's that are in use by the
>>installat
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
# from David Golden
# on Thursday 15 January 2009 21:07:
>That's probably not quite enough -- I think it means being a bit
> smarter about temp directories and files, as the M::B tests tend to
> re-use a directory over and over again. (They also seem to use both
> './t/_tmp' and './t/_tmp$$')
I h
13 matches
Mail list logo
