Tests fail on MSYS2, Windows 10

[hakonhagland]

I am trying to install Perl::LanguageServer on MSYS2, Windows 10 and it fails to install because it depends on this module, and this module has failed tests:

$ perl Makefile.PL
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for File::Copy::Recursive::Reduced
Writing MYMETA.yml and MYMETA.json

$ make
cp .README.pod blib/lib/File/Copy/Recursive/.README.pod
cp lib/File/Copy/Recursive/Reduced.pm blib/lib/File/Copy/Recursive/Reduced.pm
cp .version_info.pl blib/lib/File/Copy/Recursive/.version_info.pl
Manifying 2 pod documents

$ make test
PERL_DL_NONLAZY=1 "/usr/bin/perl.exe" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/001-fcopy.t .... 1/85
#   Failed test 'fcopy(): /tmp/IEJjn0s5v6/sym is indeed a symlink'
#   at t/001-fcopy.t line 73.

#   Failed test 'Symlink /tmp/IEJjn0s5v6/sym points to /tmp/IEJjn0s5v6/old'
#   at t/001-fcopy.t line 74.
#          got: undef
#     expected: '/tmp/IEJjn0s5v6/old'

#   Failed test 'fcopy(): but /tmp/IEJjn0s5v6/new is also another symlink'
#   at t/001-fcopy.t line 80.

#   Failed test 'fcopy(): /tmp/IEJjn0s5v6/xsym is indeed a symlink'
#   at t/001-fcopy.t line 87.

#   Failed test 'Symlink /tmp/IEJjn0s5v6/xsym points to /tmp/IEJjn0s5v6/old'
#   at t/001-fcopy.t line 88.
#          got: undef
#     expected: '/tmp/IEJjn0s5v6/old'

#   Failed test 'fcopy(): Got expected warning when copying from symlink whose target does not exist'
#   at t/001-fcopy.t line 94.
#                   ''
#     doesn't match '(?^:Copying a symlink \(/tmp/IEJjn0s5v6/xsym\) whose target does not exist)'
t/001-fcopy.t .... 80/85 # Looks like you failed 6 tests of 85.
t/001-fcopy.t .... Dubious, test returned 6 (wstat 1536, 0x600)
Failed 6/85 subtests
        (less 30 skipped subtests: 49 okay)
t/002-dircopy.t .. 1/115
#   Failed test 'Got expected number of directories, files and symlinks by copying'
#   at t/002-dircopy.t line 403.
#     Structures begin differing at:
#          $got->{files} = '9'
#     $expected->{files} = '6'

#   Failed test 'Got expected warning when copying a symlink whose target does not exist'
#   at t/002-dircopy.t line 431.
#                   ''
#     doesn't match '(?^:Copying a symlink.*?whose target does not exist)'

#   Failed test 'Got expected number of directories, files and symlinks by copying'
#   at t/002-dircopy.t line 457.
#     Structures begin differing at:
#          $got->{symlinks} = '0'
#     $expected->{symlinks} = '3'
# Looks like you failed 3 tests of 115.
t/002-dircopy.t .. Dubious, test returned 3 (wstat 768, 0x300)
Failed 3/115 subtests
        (less 26 skipped subtests: 86 okay)
t/003-rcopy.t .... 1/188
#   Failed test 'rcopy(): /tmp/6XcQ5nXz2w/sym is indeed a symlink'
#   at t/003-rcopy.t line 80.

#   Failed test 'Symlink /tmp/6XcQ5nXz2w/sym points to /tmp/6XcQ5nXz2w/old'
#   at t/003-rcopy.t line 81.
#          got: undef
#     expected: '/tmp/6XcQ5nXz2w/old'

#   Failed test 'fcopy(): but /tmp/6XcQ5nXz2w/new is also another symlink'
#   at t/003-rcopy.t line 87.

#   Failed test 'rcopy(): /tmp/6XcQ5nXz2w/xsym is indeed a symlink'
#   at t/003-rcopy.t line 94.

#   Failed test 'Symlink /tmp/6XcQ5nXz2w/sym points to /tmp/6XcQ5nXz2w/old'
#   at t/003-rcopy.t line 95.
#          got: undef
#     expected: '/tmp/6XcQ5nXz2w/old'

#   Failed test 'fcopy(): Got expected warning when copying from symlink whose target does not exist'
#   at t/003-rcopy.t line 101.
#                   ''
#     doesn't match '(?^:Copying a symlink \(/tmp/6XcQ5nXz2w/xsym\) whose target does not exist)'

#   Failed test 'Got expected number of directories, files and symlinks by copying'
#   at t/003-rcopy.t line 629.
#     Structures begin differing at:
#          $got->{files} = '9'
#     $expected->{files} = '6'
# Looks like you failed 7 tests of 188.
t/003-rcopy.t .... Dubious, test returned 7 (wstat 1792, 0x700)
Failed 7/188 subtests
        (less 56 skipped subtests: 125 okay)

Test Summary Report
-------------------
t/001-fcopy.t  (Wstat: 1536 Tests: 85 Failed: 6)
  Failed tests:  10-11, 15-17, 20
  Non-zero exit status: 6
t/002-dircopy.t (Wstat: 768 Tests: 115 Failed: 3)
  Failed tests:  82, 88-89
  Non-zero exit status: 3
t/003-rcopy.t  (Wstat: 1792 Tests: 188 Failed: 7)
  Failed tests:  10-11, 15-17, 20, 162
  Non-zero exit status: 7
Files=3, Tests=388,  4 wallclock secs ( 0.08 usr  0.08 sys +  0.76 cusr  2.23 csys =  3.15 CPU)
Result: FAIL
Failed 3/3 test programs. 16/388 subtests failed.
make: *** [Makefile:889: test_dynamic] Error 7

[jkeenan]

Thank you for this report. Since I don't have access to MSYS2 or Windows 10, I will have to depend on you to develop a correct response.

1. The AppVeyor CI report you generated -- is that with File::Copy::Recursive::Reduced as is or with Fixes issue #3. #4 applied?
2. Do you experience similar test failures with File::Copy::Recursive on this platform?
3. Are there other CPAN modules where workarounds such as you have supplied in the p.r. have been included?

Thank you very much.
Jim Keenan

[jkeenan]

Thank you for this report. Since I don't have access to MSYS2 or Windows 10, I will have to depend on you to develop a correct response.

1. The [AppVeyor CI report](https://ci.appveyor.com/project/jkeenan/file-copy-recursive-reduced/builds/39670257) you generated -- is that with File::Copy::Recursive::Reduced as is or with #4 applied?

2. Do you experience similar test failures with File::Copy::Recursive on this platform?

3. Are there other CPAN modules where workarounds such as you have supplied in the p.r. have been included?

Thank you very much.
Jim Keenan

Also, are you in a position to submit CPANtesters reports for this platform more generally?

We are chronically short of such reports on both Windows and Cygwin ... and I can't say that I've ever seen a report for MSYS2. I've only received 1 failing report for this distribution on Windows (and that report was from "anonymous" so could not be followed up on).

Thanks.
jimk

[jkeenan]

I incorporated your p.r. into #5.

Can you take test that on the platforms in question?

Thank you very much.
Jim Keenan

[hakonhagland]

Thank you. I have spotted some more issues with symlinks on Windows and will investigate a little bit more before I come back and review this..

[jkeenan]

Thank you. I have spotted some more issues with symlinks on Windows and will investigate a little bit more before I come back and review this..

Thanks.

Somewhat OT: If you're concerned with perl on Cygwin and MSYS2 more generally, you might want to take a look at and/or comment upon these tickets in Perl 5:

Perl/perl5#18534
Perl/perl5#18492

[hakonhagland]

Ok I have done some more investigation regarding this issue. Unfortunately, the situation is more complicated:

Some information about symlinks on MSYS2 and Cygwin. Tested on Windows 10.

Starting with Windows 10 Insiders build 14972, native symlinks can be created without needing to elevate the console as administrator, see

https://blogs.windows.com/windowsdeveloper/2016/12/02/symlinks-windows-10/

To enable this feature, go to "Windows Security" -> "For developers", and turn on "Developer mode". Before Windows 10 Insiders build 14972, native symlinks could still be created but needed an elevated CMD console.

[[ Note: It is possible to query (from e.g. perl) if developer mode is activated by investigating the registry key SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock ]]

How is this implemented in MSYS2 and in Cygwin? (TODO: Only tested on my current Windows 10 Home, 21H1. Does it work similarly on older windows machines?)

The behavior of the ln --symbolic <target> <destination> command in Cygwin depends on the environment variable CYGWIN, see

https://cygwin.com/cygwin-ug-net/using-cygwinenv.html

The CYGWIN environment variable is used to configure many global settings for the Cygwin runtime system. It contain options separated by blank characters. The option that is important for the ln -s command is called winsymlinks. According to the linked page above, there are four cases for the winsymlinks option to consider:

1. winsymlinks is not defined. (Note: this behavior differs from that of MSYS2, see below). This is called the default behavior for Cygwin.
   a) If native symlinks are enabled, see above, then this is equivalent to setting winsymlinks to native (e.g. CYGWIN=winsymlinks:native), see 3) below.
   b) If native symlinks are not enabled, this is equivalent to setting winsymlinks to lnk see 2) below.

2. winsymlinks is empty (MSYS=winsymlinks) or winsymlinks is set to lnk (e.g. MSYS=winsymlinks:lnk)
   Whether <target> exists or not, ln -s creates as a Windows shortcut file (with a special header and the R/O attribute set).

3. winsymlinks:native
   a) If native symlinks are enabled, and whether <target> exists or not, creates <destination> as a native Windows symlink. Note, this is most similar to the behavior of ln -s on *nix.
   b) If native symlinks are not enabled, it is equivalent to setting winsymlinks to lnk, see 2) above.

4. winsymlinks:nativestrict
   a) If native symlinks are enabled and <target> exists, creates <destination> as a native Windows symlink,
   b) else if native symlinks are not enabled or if <target> does not exist, ln -s fails.

Similiarly to the CYGWIN environment variable, the MSYS2 environment variable is used to configure global settings for the MSYS2 runtime system (since MSYS2 are based on Cygwin). The four cases for the winsymlinks option to consider is:

1. winsymlinks is not defined. The default behavior for MSYS2. (Note: this is not similar to Cygwin)
   a) If <target> exists, <target> is (surprise!!) copied to <destination>, so <destination> does not become a symlink but simply a copy of <target>, this happens whether <target> is a file or a directory, or whether native symlinks are enabled or not. See

   Coreutils: ln --symbolic creates hard links  msys2/MSYS2-packages#249

   for more information.
   b) If <target> does not exist, ln -s fails.

2. winsymlinks or winsymlinks:lnk : (Similar to Cygwin, see above)

3. winsymlinks:native : (Similar to Cygwin, see above)

4. winsymlinks:nativestrict : (Similar to Cygwin, see avove)

Next question: How does the MSYS2 and CYGWIN environment variables afffect perl?

First thing:

• On both MSYS2 and Cygwin,

   perl -MConfig -E'say $Config{d_symlink}'
  

  prints define (meaning the symlink call is implemented).

• On regular windows ($^O eq "MSWin32") with e.g. strawberry perl, $Config{d_symlink}

  • is not defined for perl versions < 5.33.5

  • is defined for perl versions >= 5.33.5, see

    https://metacpan.org/release/CORION/perl-5.33.5/view/pod/perldelta.pod#Windows

So the perl symlink function "works" on MSYS2 and Cygwin, and for newer versions of MSWin32.

For the further discussion below, consider the perl statement:

  symlink $target, $dest;

If $dest exists, the symlink command always fails (returning a value of 0 and setting $!). So consider the case where $dest does not exist: There are four cases for the winsymlinks option contained in the MSYS or CYGWIN env. variable
to consider, as above for the ln -s command. It turns out that symlink behaves identically to the ln -s command, and when ln -s fails, symlink also fails and returns a value of 0 and sets $! (ERRNO).

Also note that the environment variables MSYS or CYGWIN cannot/should not be changed from within the Perl script itself. I am not sure why this does not work, but I tested it and it showed undefined behavior in my tests. So the variables should be set before perl is run, e.g. on the command line:

  MSYS=winsymlinks:native perl p.pl

What about the perl -l operator ? Tests show that it does not differentiate between a Windows shortcut file and a native symlink file. So

  say "symlink" if -l "foobar";

prints "symlink" for both file types. Further, there seems to be no tool available to determine which of the two file types a given symlink file is. Note that there is a cygwin command readshortcut.exe that can be used to read a shortcut file (with .lnk extension).

So when we try to copy a symlink file, it is difficult to determine if the destination should be a native symlink or a windows shortcut. The user would probably expect that the destination is the same type of symlink as the source was. Note that even the cp command in MSYS2

 cp -a source destination

does in fact in general not preserve the symlink type (tested), instead the destination symlink type is determined by the MSYS2 winsymlinks option (and not the symlink type of the source).

---

I have written some code to work with this new information, see PR #6 . More tests needs to be written, but this is a first step.

[jkeenan]

I do not have access to any of Windows, Cygwin or Msys2. So while I can appreciate the time and effort you've put in to these issues, there's no way I can evaluate any given aspect of your findings.

However, it seems that what you have learned must be far from this small CPAN module's alone. It must affect the handling of symlinks on these platforms in all Perl code (and maybe not just Perl code). So it cries out for a more general solution more than a patch to this little module.

Could you write these findings up in a way that would make sense for posting on perl5-porters mailing list?

Your findings also seem blog-worthy.

Thank you very much.
Jim Keenan

[hakonhagland]

Your findings also seem blog-worthy.

Thanks for the suggestion! I have written a blog post here.. Please let me know if there are anything I could improve.