[Windows] error C2065: S_IWUSR #166
Labels
compile
There is a problem compiling libzip.
Comments
|
https://ci.appveyor.com/project/0-wiz-0/libzip/builds/32273199/job/3c8a61c5uawfq1v8 Line 629:
Maybe it's a good idea to read the AppVeyor error messages? |
|
Thanks, fixed in d8b0c31 Appyveyor consistently fails because there is one failing test, so we don't notice when it breaks for other reasons. |
|
You're welcome! I looked at the tests. First, CMake is missing a search for Perl: If perl should be used for the tests, CMake should also search for Perl first or display an error message. For example: What is Perl needed for anyway? The test system seems to be built very complicated. Some C programs are created, but they are not related to each other. The CTest then apparently calls a Perl script that performs the actual test. Why not a direct C solution like googletest? Then you only need to let CTest do it and it is easier to debug. What are all these programs for? Are they all needed for the tests? Then there is no information in which order they have to be built. Now to the actual test: Yes, a file junk-at-start.zzip does not exist either. The file in the regress directory is called junk-at-start.zip. zip and not zzip. Which program is executed for the test with which parameters (arguments, environment variables)? I can also debug this directly. The Perl script does not help me. By the way, this is the test result on my computer: |
|
We have a language in which we describe our test cases, and a perl program is used as interpreter. The one for this case is: I could explain the details, but it's probably not necessary. The case we need help with can be reduced to this recipe: Run This should print |
Return code 1 The call to |
|
Ok, so the next step is to find out why |
|
Much better! zip_source_win32handle.c (301): new_current = 0 |
|
Thanks! I noticed that the Windows backend was still using absolute values for the |
|
_zip_find_central_dir > zip_source_seek _zip_source_call > _win32_read_file (len=16, cmd=ZIP_SOURCE_SEEK) Function _zip_seek_win32 is working, but then new_offset.QuadPart is 0, ctx->start is 4 which ends up in new_current = -4. zip_source_win32handle.c in line 379 fails! |
|
Thanks for the detailed analysis, I've just committed a fix for it. (The corresponding code path is not used in the Unix file source (since we always set ctx->end), so we didn't notice it, even though the bug was present there too.) |
_zip_find_central_dir > _zip_read_cdir > _zip_dirent_read
local=false memcmp returns 1, so the function returns -1 |
|
Thanks for the quick analysis, I see the problem: the buffer should be shifted 4 bytes to the left. That means the seek did not correctly account for ctx->start. I'll take a look at it. |
|
Thank you very much for taking care of this problem! I will continue to test until all tests work under Windows. |
|
Thank you for your continued debugging support. Your bug reports are excellent. We are currently refactoring the whole file source implementation. We'll let you know when it's in a stable state again. |
|
We have completed the restructuring and all tests now pass. However, we still have a few open questions:
thanks, |
|
Excellent!
Here is the result of the tests (not UWP, 10da88f): |
|
Where did you run those tests? Could you run them with the environment variable VERBOSE set to YES, so we see what's going wrong? Thanks. |
|
Please let me know if 223c57e improves the situation for you. |
|
Hm, would it be possible to include more queries in CMake? The test system drives me crazy, because there are always some programs/commands being executed which are assumed to be present without testing if the assumption is correct. Example: Why does DIFF suddenly appear here? Why does CMake not check if DIFF is present? Yes, under Linux this is found on 90% of all installations, but not under Windows. |
Details: |
|
Ok, adding the path with diff to the environment variable PATH does not work. You have to write the complete path directly into NiHTest.pm (585). This test environment is really annoying. |
|
Comparing your run to are run for you but not in appveyor. Any ideas? (They need to preload a shared object to get rid of the randomness so we can test the encryption module.)
The |
|
These are good questions. There are also pipes under Windows (https://docs.microsoft.com/en-us/windows/win32/ipc/pipes). I would suggest to exclude the tests that do not work under Windows, so that in case of success CTest returns a positive result. The encryption tests are running but return an error: The construct to load a library in Perl to overwrite a function in another program does not work under Windows. Under Windows, the library must be loaded in the same program. I am a little bit surprised that it works under Linux. Isn't that actually a security hole? |
|
I think this issue is now resolved. Thanks. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Compiler Error
libzip Version
commit cebe19a
Operating System and Compiler
Windows 10, Visual Studio 2017
Additional context
The problem is in line 212 of the file zip_source_filep.c:
libzip/lib/zip_source_filep.c
Line 212 in 066a1b1
The constant S_IWUSR does not exist under Windows. Either the last commit is undone at this position, or the following code is added after the includes at the beginning of the file:
The text was updated successfully, but these errors were encountered: