File-Find-1.39 (and later) breaks Module::Pluggable and Module::Find #19995
Comments
(If Module::Find has fewer CPAN prerequisites that Module::Pluggable, use that instead.) |
|
If it helps, here's the diff between File/Find.pm versions 137 and 1.39. Also, there's some previous discussion about this starting at StrawberryPerl/Perl-Dist-Strawberry#39 (comment) |
|
On Tue, Jul 26, 2022 at 4:42 AM James E Keenan ***@***.***> wrote:
1. Has this been observed on any operating system other than Windows?
No. (Sorry - I should have made that clear.)
Apart from the bump of version number, there's only a couple of lines of
code that changed between version 1.37 and 1.39, and it's specifically
directed at MS Windows.
1. Would you be able to bisect this problem on Windows? With an
invocation (from a git checkout of the core distribution) something like
one of these two:
perl Porting/bisect.pl --module=Module::Pluggable \
--start=c1ec4bdd803f587dd2ae76548bca0ae59d0fe84b \
--end=1380c4f3b8014de5b3d8522690cff7ac5c6162b9
perl Porting/bisect.pl --module=Module::Pluggable \
--start=v5.32.0 \
--end=v5.34.0
(If Module::Find has fewer CPAN prerequisites that Module::Pluggable, use
that instead.)
Seems like overkill to me.
If you look at the diff (that I submitted after you posted) I think (hope)
you'll see that the change that has produced this problem is pretty clear
and pretty simple.
Cheers,
Rob.
|
|
On 7/25/22 15:05, sisyphus wrote:
On Tue, Jul 26, 2022 at 4:42 AM James E Keenan ***@***.***>
wrote:
>
> 1. Has this been observed on any operating system other than Windows?
>
>
No. (Sorry - I should have made that clear.)
Apart from the bump of version number, there's only a couple of lines of
code that changed between version 1.37 and 1.39, and it's specifically
directed at MS Windows.
>
> 1. Would you be able to bisect this problem on Windows? With an
> invocation (from a git checkout of the core distribution) something like
> one of these two:
>
> perl Porting/bisect.pl --module=Module::Pluggable \
> --start=c1ec4bdd803f587dd2ae76548bca0ae59d0fe84b \
> --end=1380c4f3b8014de5b3d8522690cff7ac5c6162b9
>
> perl Porting/bisect.pl --module=Module::Pluggable \
> --start=v5.32.0 \
> --end=v5.34.0
>
> (If Module::Find has fewer CPAN prerequisites that Module::Pluggable, use
> that instead.)
>
Seems like overkill to me.
If you look at the diff (that I submitted after you posted) I think (hope)
you'll see that the change that has produced this problem is pretty clear
and pretty simple.
That diff encompasses a range of commits. When we're diagnosing BBCs,
we try whenever possible to identify the exact commit that is associated
with the breakage. The first start/end pair is a small range which I
suspect encompasses the range in your diff.
Attempting this bisection would have the additional benefit that it
would let us know whether Porting/bisect.pl works on Windows or not.
Thank you very much.
Jim Keenan
|
However since it appears to be an issue with symlinks, looking first at 0d00729 would seem like a reasonable thing to do.
If you want someone to check if bisection works on Windows, it would be better to ask for that specifically - ideally from someone that is already familiar with how the bisect tool works. |
Agreed |
karenetheridge
added
the
ext-File-Find
I just want to point out that, for the purposes of understanding what has changed between perl-5.32.x and perl-5.34.0, one only has to look at the changes in that commit that were made to Find.pm. So, ignoring the Find.pm version bump, the only code changes were that: and But this change apparently doesn't allow for some subtle difference between Windows and non-Windows systems. On the face of it, my hunch is that this should be addressed in File::Find ... but my understanding of what's happening here is poor, and maybe it's instead something that Module::Pluggable and Module::Find need to address. Cheers, |
Can you actually describe the difference in results between 1.37 and 1.39. That would help in figuring out what is truly going on. Just a wild hunch: what do the first two values of |
I was thinking that the patch to Module::Pluggable (at #19995 (comment)) which works around the issue would be the key to understanding what's going on ... and completely overlooked the fact that the actual failures themselves had not been provided. as it was in File-Find-1.37.
Sorry ... what do you want me to Cheers, |
A symlink. Any symlink. |
|
@nanis implemented a fix for this issue a few months ago, but it was never submitted as a PR. He wrote about it on his blog (part 1, part 2). It's a hack, but I don't think we could do better without completely rewriting File::Find. That module is a mess. I'll clean-up his code and submit it as a PR soon. |
Cheers, |
File::Find's code expects unix-style paths and it manipulates them using basic string operations. That code is very fragile, and ideally we should make it use File::Spec, but that would involve rewriting almost the whole module. Instead, we made it convert backslashes to slashes and handle drive letters. Note from xenu: this commit was adapted from the PR linked in this blogpost[1]. I have squashed it, written the commit message and slightly modified the code. [1] - https://www.nu42.com/2021/09/canonical-paths-file-find-way-forward.html Fixes Perl#19995
File::Find's code expects unix-style paths and it manipulates them using basic string operations. That code is very fragile, and ideally we should make it use File::Spec, but that would involve rewriting almost the whole module. Instead, we made it convert backslashes to slashes and handle drive letters. Note from xenu: this commit was adapted from the PR linked in this blogpost[1]. I have squashed it, written the commit message and slightly modified the code. [1] - https://www.nu42.com/2021/09/canonical-paths-file-find-way-forward.html Fixes Perl#19995
|
And here it is: #20008 |
You should be able to create a symlink in an elevated shell on either1, using For a fully updated windows 10, you can enable developer mode and normal users will be able to create symbolic links. Perl's symbolic link creation support depends on an API added in Vista. Footnotes
|
File::Find's code expects unix-style paths and it manipulates them using basic string operations. That code is very fragile, and ideally we should make it use File::Spec, but that would involve rewriting almost the whole module. Instead, we made it convert backslashes to slashes and handle drive letters. Note from xenu: this commit was adapted from the PR linked in this blogpost[1]. I have squashed it, written the commit message and slightly modified the code. [1] - https://www.nu42.com/2021/09/canonical-paths-file-find-way-forward.html Fixes #19995
File::Find's code expects unix-style paths and it manipulates them using basic string operations. That code is very fragile, and ideally we should make it use File::Spec, but that would involve rewriting almost the whole module. Instead, we made it convert backslashes to slashes and handle drive letters. Note from xenu: this commit was adapted from the PR linked in this blogpost[1]. I have squashed it, written the commit message and slightly modified the code. [1] - https://www.nu42.com/2021/09/canonical-paths-file-find-way-forward.html Fixes Perl#19995
0.16, 2022-08-01
Fixes an issue where symlink tests failed on systems that do not
support creation of symlinks. The issue appears on Windows
systems due to changed behaviour in "File::Find" described in
perl5/issue #19995 <Perl/perl5#19995>
Symlink tests were previously skipped if symlink() is not
available, and now also if creation of a symlink is not
possible.
Fixes issue #9 <crenz/Module-Find#9>.
Note that on Windows system, the patch to "File::Find" from
perl5/PR #20008 <Perl/perl5#20008> will
be required for proper operation.
Module:
File::Find
Version 1.37 (which shipped with perl-5.32.x) is ok. I can't find version 1.38 in any stable perl release.
The problem is arising only with version 1.39 (which shipped with perl-5.34.0) and later.
Description
Module::Pluggable and Module::Find fail tests because of the new changes wrt Win32 symlinks support in File::Find.
Both MSVC-built and MinGW-built perls are affected in the same way.
Steps to Reproduce
cpan -i Module::Pluggable
cpan -i Module::Find
The question is:
Should Module::Pluggable and Module::Find be patched to accommodate these recent changes to File::Find, or should File::Find be patched such that it doesn't break these 2 cpan modules in the first place ?
The Module-Pluggable bug report is at simonwistow/Module-Pluggable#24.
This patch to Module-Pluggable-Object.pm allows Module::Pluggable to build successfully against these problematic versions of File::Find:
There's a bug report for Module::Find at crenz/Module-Find#9 .
No patch for that one, yet, AFAIK.
I'm on a Windows 7 machine - which might be relevant.
I'm not sure which Windows version is being used by the others who have hit this issue.
As the latest Strawberry Perl is still at 5.32.1 (File-Find-1.37), the number of these "others" is probably quite small.
Perl configuration
The text was updated successfully, but these errors were encountered: