mirror of
https://github.com/jmcnamara/libxlsxwriter.git
synced 2026-05-15 14:15:54 -06:00
[GH-ISSUE #176] Corrupt output filename on windows #142
Labels
No labels
awaiting user feedback
bug
cmake
cmake
docs
feature request
in progress
long term
medium term
medium term
pull-request
question
question
ready to close
short term
under investigation
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/libxlsxwriter#142
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @dirkvdb on GitHub (May 15, 2018).
Original GitHub issue: https://github.com/jmcnamara/libxlsxwriter/issues/176
Originally assigned to: @jmcnamara on GitHub.
When I write a workbook to disk the output filename is corrupt. In my case a file with the name "C" is output.
Cause:
In packager.c:_open_zipfile_win32 the filename is converted to wchar_t and passed as a void pointer to zipOpen2_64.
Eventually in iowion32.c:win32_open64_file_func this void pointer is passed to CreateFile by casting it to LPCSTR, since my program is not compiled with unicode but multibyte character set, this is an invalid cast and results in a corrupt filename.
@jmcnamara commented on GitHub (May 15, 2018):
Can you show the steps to reproduce this.
@dirkvdb commented on GitHub (May 15, 2018):
Compile this program
The output file will not get created.
Linked against libxlsxwriter lib compiled as described in #175
@jmcnamara commented on GitHub (May 15, 2018):
I don't think your app needs to be compiled with Unicode but the library does. Try the CMake instructions below.
@jmcnamara commented on GitHub (May 15, 2018):
Open a Windows CMD or Command Window and set up your MSVC environment, if required.
Then create a work directory and and an install directory that the include and library files will be installed to.
Build the Zlib library:
Build the xlsxwriter library :
Create a new Win32 Console (or other C/C++) application in Visual Studio:
Change the ARCH to "x64" (or to match the parameter to cmake).
Replace the empty main with a libxlsxwriter example, make sure to maintain the "stdafx.h" include:
Edit the application properties:
Set the libxlsxwriter include path to match the path used above:
Set the linker directories to match the path created above:
Set the linker additional libraries to match the zlib and xlsxwriter libs created above:
Build the solution and run the output executable. It should create a hello_world.xlsx file in the same directory you ran it from.
@dirkvdb commented on GitHub (May 15, 2018):
I performed very similar steps, as soon as I put a space in the filename the file was not created anymore. I'm pretty sure projects generated with the "Visual Studio 14 Win64" generator default to multi byte instead of unicode.
@jmcnamara commented on GitHub (May 15, 2018):
It does. I thought that the CmakeList had been modified to ensure Unicode but I didn't merge that change in the end.
That isn't the same issue as a the file name truncation issue you reported. The above Cmake recipe and code will generated a file called "hello world.xlsx" without issue. I just tested it.
So can you try the above, see if it works, and then we can figure out what is the difference with your setup.
@dirkvdb commented on GitHub (May 16, 2018):
In my test I was still using release 0.7.6.
It appears to be fixed in master by this commit:
3b25ad611b (diff-ea69bda3932b6e3711b5bee1a83d7ed5)@jmcnamara commented on GitHub (May 16, 2018):
This is why I asked for the steps to reproduce the issue and why I didn't mention this fix when you indicated that you were using a git clone.
Nevertheless, this fix should be packaged up into a release. I've haven't had a chance to do that recently but I'll try get to it on the weekend.
Thanks for following up. Closing this issue.