Le Mer 06 Fév 2019 11:44:03, TINITA a écrit :
Show quoted text> On Tue Oct 11 15:26:21 2016, NHORNE wrote:
> > If this helps, I can't reproduce the problem on Windows XP, only on
> > Windows 10. My gut feeling is that something has changed in the
> > permissions scheme that Windows now uses and that causes the
> > breakage.
>
>
> Indeed it seems to be a permission problem!
> I was sitting together with Paul Boldra today who has the same problem
> (on Windows 10 I believe), after updating cygwin.
> We found out that the correct error message is actually lost, because
> of how File::Copy::move() works.
> It attempts to do a rename() first. If this fails, it tries other
> methods, and we haven't completely found out why the second attempt
> (with copy() and unlink()) produces a different error message, but:
>
> * The error message from rename() is "Permission denied"
> * If we put a "sleep 1" after the rename, it suddenly works
>
> So it has todo with copying many files after each other.
>
> For the record: CPAN::VERSION=2.18; File::Copy::VERSION=2.32, perl
> 5.26
>
I can confirm this on Windows 7 SP1 (64-bit) with Cygwin-x86_64 v3.0.7-1, Perl v5.26.3, File::Copy v2.32, so this is not only a Windows 10 problem.
These packages failed CPAN installation:
- Crypt::Mode::CBC
- Crypt::Mode::ECB
- HTML::Tidy
- Excel::Writer::XLSX
- Spreadsheet::ParseXLSX
Other, more lightweight, packages installed correctly before and after these, e.g. Module::Build or XML::XPathEngine.
As mentioned by Tina Müller, this dirty hack allows the listed failing packages to install normally (albeit a bit slowly when moving files):
--- Copy.pm 2019-09-24 17:00:39.291599500 +0200
+++ Copy-hacked.pm 2019-09-24 17:00:28.903599500 +0200
@@ -278,7 +278,9 @@
1 while unlink $to;
}
+ sleep(1);
return 1 if rename $from, $to;
+ sleep(1);
# Did rename return an error even though it succeeded, because $to
# is on a remote NFS file system, and NFS lost the server's ack?
Feel free to contact me if you need further tests.
RT for rt.cpan.org