Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test for executable called '0' fails on Windows #8

Closed
nanis opened this issue Mar 1, 2016 · 22 comments

Comments

Projects
None yet
3 participants
@nanis
Copy link

commented Mar 1, 2016

The code for fixing issue #7 is correct, but the test causes a spurious failure due to lack of a 0.exe (or 0.cmd or 0.bat or any other file with basename 0 and extension listed in %PATHEXT%. The fix is to include one with the distro.

@eserte

This comment has been minimized.

Copy link

commented Mar 1, 2016

@nanis

This comment has been minimized.

Copy link
Author

commented Mar 1, 2016

Hmmmm ... I must admit I only looked at the cpanm work directory -- which I have since nuked after manually installing it.

When I download the distro manually, and extract using GNU tar, I do get both 0 and 0.exe. However, when cpanm does it (using Archive::Tar, I assume) I get only 0.

Apologies for the misdirected report. I also happened to submit the test result to CPANTesters before seeing your response. Sorry. And, thank you.

@nanis nanis closed this Mar 1, 2016

@nanis

This comment has been minimized.

Copy link
Author

commented Mar 1, 2016

Actually, I am going to have to correct myself again: Yes, tar -xvf ... does show both files, but only 0 can be found in the extracted directory. I can see 0 gets extracted after 0.exe.

Curious.

@eserte

This comment has been minimized.

Copy link

commented Mar 1, 2016

I just tried PLICEASE/File-Which-1.20.tar.gz in a Windows VM which an old StrawberryPerl (5.18.1 or so): no problems, see test suite passed. CPAN.pm was used here, and it seems that Archive::Tar was used for extraction.

@nanis

This comment has been minimized.

Copy link
Author

commented Mar 1, 2016

Is there a 0.exe file in t\test-bin?

@eserte

This comment has been minimized.

Copy link

commented Mar 1, 2016

Both 0 and 0.exe.

@nanis

This comment has been minimized.

Copy link
Author

commented Mar 1, 2016

Interesting. Thank you for checking. I tried MinGW tar and Cygwin tar, and both resulted in only 0 being created in t\test-bin. I am not sure what the real problem is at the moment, apologies for wasting your time with my misdiagnosis.

@eserte

This comment has been minimized.

Copy link

commented Mar 1, 2016

I can confirm that cygwin tar does not extract 0.exe. It also does not extract all.exe, but test1.exe is extracted.

@nanis

This comment has been minimized.

Copy link
Author

commented Mar 1, 2016

Interesting. This all worked on a 32-bit Vista laptop, which makes it even more curious. Hmmm ...

@nanis

This comment has been minimized.

Copy link
Author

commented Mar 1, 2016

As for all.exe ... Very curious. I get all, all.bat and no all.exe. I had overlooked that.

But, on the Vista-32 machine, I get all three with cpanm, but not if I invoke Cygwin tar. Weird.

@nanis

This comment has been minimized.

Copy link
Author

commented Mar 1, 2016

So, on the affected machine, I created to zero byte files, test and test.exe. Then, using Cygwin tar, I did:

$ tar -cvf test.tar test.exe test

Then, I switched to another directory, and did:

$ tar -xvf /some/path/test.tar

After this, the directory only had test. However, if I created test.tar using tar -cvf test.tar test test.exe, I got both files.

This clearly is not a problem with File::Which. I am not sure if I have the energy to pursue this to the end. However, File::Which may defend against this by putting Windows specific executables in test-bin\windows or something like that.

This is definitely a problem with GNU tar. On the original machine, my %PATH% actually had a GNUtarexecutable soArchive::Tar` was not used.

@eserte

This comment has been minimized.

Copy link

commented Mar 1, 2016

Seems to be an old problem: https://cygwin.com/ml/cygwin/2012-07/msg00201.html

The test-bin\windows solution could work, or simply not bundling the test exe files, but "touching" them during Makefile.PL execution.

@nanis

This comment has been minimized.

Copy link
Author

commented Mar 1, 2016

Good detective work. My searches were not fruitful. Of course, I cannot understand how this could be "by design" as mentioned later in that thread, and "you are starting to bore. it seems that you ignored every info given to you" is very telling.

@nanis

This comment has been minimized.

Copy link
Author

commented Mar 1, 2016

From what I can understand, the behavior only kicks in case there is an exe file. So, maybe you can rename 0.exe to 0.bat ... That would be the smallest change which avoids this behavior.

@plicease

This comment has been minimized.

Copy link
Owner

commented Mar 1, 2016

The test suite should test against both 0.exe and 0.bat on MSWin32 and cygwin. I have to take a closer look to see if it actually does. But renaming 0.exe to 0.bat isn't really an option for that reason. I can alter the test suite to create the files rather than bundling. First I will see first if I can reproduce the issue myself, and make an appropriate fix. Agreed that this isn't a File-Which bug, but that File-Which should make an effort to work around it. When I made the changes for #7 I did actually test it on Strawberry and cygwin, but from the git repository, not from the tarball :P

@plicease plicease reopened this Mar 1, 2016

@nanis

This comment has been minimized.

Copy link
Author

commented Mar 1, 2016

Here's the rationale: https://sourceware.org/ml/cygwin/2009-08/msg00293.html

I can confirm that the same behavior also occurs with the MinGW compiled tar distributed with git alongside Visual Studio 2015.

@plicease

This comment has been minimized.

Copy link
Owner

commented Mar 1, 2016

Thanks for the details. I don't anticipate this should be hard to fix.

@plicease

This comment has been minimized.

@plicease

This comment has been minimized.

Copy link
Owner

commented Mar 2, 2016

I wasn't able to reproduce this with either bsdtar or tar on my cygwin. However, I separated the null suffix and .exe files into separate directories and adjusted the test suite appropriately and tested on Linux, cygwin and Strawberry. I have released this as 1.21. I believe this should work around the issue, but please reopen with details if you find this not to be the case. Thanks again to both of you for the analysis.

@plicease plicease closed this Mar 2, 2016

@nanis

This comment has been minimized.

Copy link
Author

commented Mar 3, 2016

Yup. It works. Thank you very much. Passing test report should hit CPANTesters soon.

@plicease

This comment has been minimized.

Copy link
Owner

commented Mar 7, 2016

for anyone stumbling across this and might be interested in more analysis: https://www.nu42.com/2016/03/tar-anomaly.html

Also, I finally was able to see a tar unpacking the way @nanis originally described, by using a tarball built on Linux, and extracted on cygwin. I wasn't seeing this problem with tarballs built on cygwin and extracted on cygwin. The order of the files in the tar may matter (?).

@nanis

This comment has been minimized.

Copy link
Author

commented Mar 7, 2016

@plicease First, thanks for mentioning my blog.

Second, yes, the order of the files in the tar archive does matter as shown in the screenshot below:

screenshot

With tar -cvf test.tar test test.exe, you get both test and test.exe when you extract the contents.

On the other hand, if you do tar -cvf test.tar test.exe test, you only get test when you extract the contents.

None of this is very natural or intuitive, but it is the way things are. One way to avoid being hit by this is to build libarchive and all its dependencies using only the Microsoft toolchain, or, possibly, by using Perl Power Tools.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.