Skip Menu |
 

This queue is for tickets about the Module-Build CPAN distribution.

Report information
The Basics
Id: 80696
Status: open
Priority: 0/
Queue: Module-Build

People
Owner: Nobody in particular
Requestors: NWELLNHOF [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: (no value)
Fixed in: (no value)

Attachments


Subject: "Build clean" fails on Windows
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 453
Download (untitled) / with headers
text/plain 453b
I get lots of random failures when running "Build clean" on Windows that look like: Couldn't remove 'dir': That's because 'delete_filetree' in Module::Build::Base checks whether the file or directory still exists after deletion. But on Windows, deleted files are still visible in the file system as long as another process (for example a virus scanner) has an open handle on that file. So can you please disable this check on Windows platforms?
MIME-Version: 1.0
X-Mailer: MIME-tools 5.504 (Entity 5.504)
X-RT-Interface: API
Content-Type: multipart/mixed; boundary="----------=_1368803251-16624-2"
Message-ID: <rt-4.0.12-16624-1368803251-281.0-0-0 [...] rt.cpan.org>
Message-ID: <rt-4.0.12-16624-1368803251-1659.80696-0-0 [...] rt.cpan.org>
X-RT-Original-Encoding: utf-8
Content-Length: 0
Content-Disposition: inline
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 563
Download (untitled) / with headers
text/plain 563b
I also get this problem, it seems that under windows there can sometimes be a short delay between a file being removed and you running in perl -e($_) and getting false. I made a patch for Module build 0.4005 that could address this issue without noticeable performance impact for other platforms. It simply does the following File::Path::rmtree($_, 0, 0) or die "Couldn't remove '$_': $!\n"; sleep 1 if (-e $_); die "Couldn't remove '$_': $!\n" if -e $_; instead of File::Path::rmtree($_, 0, 0); die "Couldn't remove '$_': $!\n" if -e $_;
MIME-Version: 1.0
Subject: Module-Build-0.4005-Module-Build-Base.pm.patch
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Type: application/octet-stream; name="Module-Build-0.4005-Module-Build-Base.pm.patch"
Content-Disposition: inline; filename="Module-Build-0.4005-Module-Build-Base.pm.patch"
Content-Transfer-Encoding: base64
Content-Length: 494
diff --git "a/Module/Build/Base.pm" "b/Module/Build/Base-patched.pm" index 5fb8506..133facb 100644 --- "a/Module/Build/Base.pm" +++ "b/Module/Build/Base-patched.pm" @@ -5296,7 +5296,8 @@ sub delete_filetree { foreach (@_) { next unless -e $_; $self->log_verbose("Deleting $_\n"); - File::Path::rmtree($_, 0, 0); + File::Path::rmtree($_, 0, 0) or die "Couldn't remove '$_': $!\n"; + sleep 1 if (-e $_); die "Couldn't remove '$_': $!\n" if -e $_; $deleted++; }
MIME-Version: 1.0
In-Reply-To: <rt-4.0.12-16624-1368803251-281.0-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.12-16624-1368803251-281.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.12-9575-1369151707-425.80696-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 468
Download (untitled) / with headers
text/plain 468b
On Fri May 17 11:07:31 2013, https://mafoo.pip.verisignlabs.com/ wrote: Show quoted text
> sleep 1 if (-e $_);
I don't think this is a good solution. It simply hides the problem and it would slow down cleaning of the project I work on a lot. Simply dropping the check on Windows ($^O eq 'MSWin32') seems like the best idea to me. The -e check should work on Cygwin, btw. Anyone who's interested in this notorious issue is encouraged to have a look at Cygwin's unlink_nt function.
From fawaka [...] gmail.com Tue May 21 13: 10:49 2013
MIME-Version: 1.0
X-Spam-Status: No, score=-4.993 tagged_above=-99.9 required=10 tests=[AWL=1.227, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_HI=-5, SPF_NEUTRAL=0.779] autolearn=ham
In-Reply-To: <rt-4.0.12-9575-1369151707-1955.80696-5-0 [...] rt.cpan.org>
X-Spam-Flag: NO
X-RT-Interface: API
References: <RT-Ticket-80696 [...] rt.cpan.org> <rt-4.0.12-16624-1368803251-281.80696-5-0 [...] rt.cpan.org> <rt-4.0.12-9575-1369151707-1955.80696-5-0 [...] rt.cpan.org>
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
X-Received: by 10.112.11.137 with SMTP id q9mr1093217lbb.24.1369156233392; Tue, 21 May 2013 10:10:33 -0700 (PDT)
Message-ID: <CAHhgV8g-=V7Ppk3_oQK3e9nyqR-gZ7=igxU=ahf3R=vr98Ffmw [...] mail.gmail.com>
content-type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
X-Spam-Score: -4.993
Authentication-Results: hipster.bestpractical.com (amavisd-new); dkim=pass header.i= [...] gmail.com
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 190772409D8 for <cpan-bug+Module-Build [...] hipster.bestpractical.com>; Tue, 21 May 2013 13:10:49 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owKUzLsbuGKT for <cpan-bug+Module-Build [...] hipster.bestpractical.com>; Tue, 21 May 2013 13:10:47 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id 0871D2409D5 for <bug-Module-Build [...] rt.cpan.org>; Tue, 21 May 2013 13:10:46 -0400 (EDT)
Received: (qmail 1769 invoked by alias); 21 May 2013 17:10:46 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com) (209.85.217.173) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Tue, 21 May 2013 10:10:38 -0700
Received: by mail-lb0-f173.google.com with SMTP id t10so1082534lbi.18 for <bug-Module-Build [...] rt.cpan.org>; Tue, 21 May 2013 10:10:33 -0700 (PDT)
Received: by 10.112.78.203 with HTTP; Tue, 21 May 2013 10:10:13 -0700 (PDT)
Delivered-To: cpan-bug+Module-Build [...] hipster.bestpractical.com
Subject: Re: [rt.cpan.org #80696] "Build clean" fails on Windows
Return-Path: <fawaka [...] gmail.com>
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=i7ejrpUmlt0ze9md0V/mrau3jmDDHZ+lDm4OA1LyXrc=; b=FFxiTLQxFyaaLsYn/YVc43JOtA6SB39kWauG/70F2md7t5OYRZtpfSMiKCIueeJSC/ WrFrRgf2p35pPncAofL9MjhyjzM9ClCh4IaTLxRdVy2BhoqzCJ42bfTxhskxb03xMo7p wVIDhPLgRtu2Usk4y1OpyODyYehu232tGSxUUC/R7jn0vF29AIvfrlJBVz4G0V400e+k H3Qm4aentmap1yz9f8lr1yrjJc7s5H9vNb+i0+uHgynITZNNdMXx4r2Ww+3Sk5c9i02J uKbQqblNvJyLH4DWmzORnyzNkGFPIC1ZtG3lpEYL7ZlGh5W3NjpbMrFkuaBSFqo0rR9o /ikQ==
X-Spam-Check-BY: la.mx.develooper.com
X-Original-To: cpan-bug+Module-Build [...] hipster.bestpractical.com
X-RT-Mail-Extension: module-build
Date: Tue, 21 May 2013 19:10:13 +0200
X-Spam-Level:
To: bug-Module-Build [...] rt.cpan.org
From: Leon Timmermans <fawaka [...] gmail.com>
RT-Message-ID: <rt-4.0.12-9575-1369156249-1616.80696-0-0 [...] rt.cpan.org>
Content-Length: 645
Download (untitled) / with headers
text/plain 645b
On Tue, May 21, 2013 at 5:55 PM, Nick Wellnhofer via RT <bug-Module-Build@rt.cpan.org> wrote: Show quoted text
> Queue: Module-Build > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=80696 > > > On Fri May 17 11:07:31 2013, https://mafoo.pip.verisignlabs.com/ wrote:
>> sleep 1 if (-e $_);
> > I don't think this is a good solution. It simply hides the problem and it would slow down cleaning of the project I work on a lot. Simply dropping the check on Windows ($^O eq 'MSWin32') seems like the best idea to me.
I agree this is a rather poor solution. And TBH I'm wondering if this isn't a bug in File::Path instead of Module::Build. Leon
MIME-Version: 1.0
In-Reply-To: <rt-4.0.12-9575-1369156249-1616.80696-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <RT-Ticket-80696 [...] rt.cpan.org> <rt-4.0.12-16624-1368803251-281.80696-5-0 [...] rt.cpan.org> <rt-4.0.12-9575-1369151707-1955.80696-5-0 [...] rt.cpan.org> <CAHhgV8g-=V7Ppk3_oQK3e9nyqR-gZ7=igxU=ahf3R=vr98Ffmw [...] mail.gmail.com> <rt-4.0.12-9575-1369156249-1616.80696-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.12-10567-1369156795-1022.80696-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 470
Download (untitled) / with headers
text/plain 470b
On Tue May 21 13:10:49 2013, fawaka@gmail.com wrote: Show quoted text
> And TBH I'm wondering if this > isn't a bug in File::Path instead of Module::Build.
AFAICS, File::Path doesn't guarantee POSIX file deletion semantics. And it's really hard to approximate them on Windows. I'd simply change the check to: # Windows doesn't guarantee that files and directories # disappear from the file system immediately. die "Couldn't remove '$_': $!\n" if $^O ne 'MSWin32' && -e $_;
MIME-Version: 1.0
In-Reply-To: <rt-4.0.12-9575-1369151707-425.80696-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: API
References: <rt-4.0.12-16624-1368803251-281.0-0-0 [...] rt.cpan.org> <rt-4.0.12-9575-1369151707-425.80696-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.13-21990-1374661357-1753.0-0-0 [...] rt.cpan.org>
Message-ID: <rt-4.0.13-21990-1374661357-588.80696-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
From: Matthew Vale
Content-Length: 1384
Download (untitled) / with headers
text/plain 1.3k
I agree that it could add delay to larger project due to the number of sleeps but I don't agree about ignoring the result of the file delete and feel it should be stopped if there was a problem otherwise your build could have issues! That is why I proposed the compromise of sleep only 1 second if the file still exists after asking for it to be deleted then give up if it still remained. generally what i found was that 1 file of many would cause the delay to kick but it was enough to keep the build running. it's NOT adding 1 second x number of files to be deleted, it only does +1 second per file that failed to complete it's delete first time. I think what is happening is under windows the delete operation goes of and runs asynchronously where as under unix and other os's it is running synchronously. Realistically the File::Path::rmtree needs adjusting to cope with this artefact. An alternative compromise would be create a temporary directory inside the build location (so you are not cross filesystem) then use the move operation on an item first going into the temp folder (to get the files out of the way of the build) then trigger the delete. this would mean it doesn't matter if there is a delay between asking for it to be deleted and it actually going as the file/directory being removed is not in the build location it has for all intensive purposes been deleted.
MIME-Version: 1.0
In-Reply-To: <rt-4.0.13-21990-1374661357-1753.0-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: API
References: <rt-4.0.12-16624-1368803251-281.0-0-0 [...] rt.cpan.org> <rt-4.0.12-9575-1369151707-425.80696-0-0 [...] rt.cpan.org> <rt-4.0.13-21990-1374661357-1753.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.13-21987-1374661747-944.0-0-0 [...] rt.cpan.org>
Message-ID: <rt-4.0.13-21987-1374661747-674.80696-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
From: Matthew Vale
Content-Length: 385
Download (untitled) / with headers
text/plain 385b
Something like this would make the alternate compromise work (this is untested, just spooling of the top of my head) File::Copy::move($_, $_."_deleting"); File::Path::rmtree($_."_deleting", 0, 0) or die "Couldn't remove '$_"."_deleting': $!\n"; die "Couldn't remove '$_"."_deleting': $!\n" if -e $_; instead of File::Path::rmtree($_, 0, 0); die "Couldn't remove '$_': $!\n" if -e $_;


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.